システム開発で思うところスマートフォン用の表示で見るシステム開発で思うところJavaで主にシステム開発をしながら思うところをツラツラを綴る。Sample(実践編1)Annotation以前の記事の続きです。続けたいと思っています。はじめに開発環境Java8、Maven、Netbeans8.2コード全てのリポジトリは以下のプロジェクトに格納しています。https://bitbucket.org/account/user/vermeerlab/projects/AN目指したところライブラリ群として沢山のAPIを作成しておいて必要なものだけを使用するような仕組みがあると嬉しい統一した処理が出来るようにインターフェースを準備するAPIの作成と登録(基本)基本となる機能や使い方についての説明です。実行クラスパスとしては「テスト」内なので違和感があるかもしれませんが、テスト実施と基本ライブラリにサンプルを持っておきたいと考えた結果、このような構成になっています。対象を特定するAnnotationを作成マーカーとなるAnnnotationインターフェース(TestScan.class)を作成します。このインターフェースを記載している要素が処理対象となります。{}実行するコマンドクラスの作成インターフェース:ProcessorCommandInterfaceを実装したクラスを作成します。ラウンド毎に実行するコマンドです。}}メソッド:getTargetAnnotationの戻り値として設定した値が処理対象となるAnnotationインターフェースです。今回はTestScan.classです。メソッド:executeをProcessorラウンドにて実行します。今回は検証を行います。Javaコードの生成は行っていません*1。最後に実行するコマンドクラス(任意)の作成インターフェース:PostProcessorCommandInterfaceを実装するクラスを作成します。本クラスの作成は任意です。用途としてはAnnotationで処理全体の結果を踏まえて何かをしたい時に使用します。サンプルでは処理件数を標準出力しています。}}検証クラス(任意)を作成インターフェース:ValidationInterfaceを実装するクラスを作成します。本クラスの作成は任意であり、またヘルパークラス用のものなので使用も任意です。用途としてはAnnotationで取得した要素(Element)に対して何かしらの検証を行う際に使用する統一インターフェースです。}}コマンドクラスのexecute()内でCommandValidator#validateの引数にすることで、複数の検証クラスを一度に実行できるヘルパーに使用することが出来ます。したがって、自分で検証の仕組みを設けたい場合は、使う必要もありません。サンプルではクラス名によって検証を行っています。*2上述のコードだと以下の部分です。CommandValidator.of(TestScan.class);validator.validate(TestScanValidation.of(element));validator.validateの引数は複数指定できるので、elementの種類毎に色々な検証をしたい場合にイテレーターパターンで検証をします。いうか、それだけのヘルパーです。実行クラスパスとして今回はテストクラスパス内のresources配下のprocessor-command.xmlに実行するコマンドとして作成したコマンドクラスを指定します。メインパッケージのresourcesにprocessor-command.xmlが存在しますが、これはライブラリの基本構造を示すということと、基本ライブラリをそのままForkして拡張することを鑑みた対処です。したがってファイル内に実行するコマンドクラスの指定をする記載もしていません。コンパイルコンパイルによりAnnotationProcessorが動いたように思えますが、実際はテストクラスにて実行されただけです。今回のケースではコード生成をしていないのでtarget配下にコードが作成されることはありません。APIの作成と登録(拡張)基本となるライブラリを使用して独自のAnnotationProcessorライブラリを作成してみたいと思います。実際に作ったコマンドは前回の記事でやったこととほぼ同じことをするものにしました*3。説明は基本編との差分のみにします。BitbucketMaven基本ライブラリを依存ライブラリとして追加します。加えてAnnotationProcessorを使うときにお約束になるコンパイル時の指定を追記します*4。『APIの作成と登録(基本)』ではテスト内に作成しましたが、今回はきちんとメインパッケージに実装をします。コマンド実行クラス:SampleCommand.java処理対象アノテーション:TargetClass.java、TargetField.java作成したAPIを登録テストのためにテストパッケージのprocessor-command.xmlに登録をしています。メインパッケージのresourcesにprocessor-command.xmlを作成する必要もありませんし、もしファイルがあったとしても作成したコマンドを追記する必要はありません。}}APIを利用するクライアント作成したAPI群を使用するクライアント側プロジェクトです。それを使う側の手順になります。拡張API群をMavenでコンパイルしてローカルにMavenリポジトリが存在していること*5。Mavenpom.xml(関連個所のみ。</configuration></plugin>実装AnnotationProcessorの処理対象となるAnnotationインターフェース(@TargetClass)が設定されている生成トリガーとなるコードは、拡張APIのテストコードとほぼ同じなので省略します。エラーになっています。コンパイル前にエラーになっていたクラスからエラーが消えました。さいごにメリット使い方がシンプルクライアント側はライブラリの依存だけとAnnotationProcessorを動かすための記述をすれば良いだけです。いう操作をしようとしているのか分かるのでブラックボックスでは無いと思います。機能の提供側としては機能一覧としてprocessor-command.xmlに記載する内容を提示しておいて、利用側が必要なものを選択する、または不要なものを外すことで対応可能です。実行ライブラリのクラスパスにprocessor-command.xmlを配置しないといけないません。利用側が自分のresources配下に機能一覧を追記したprocessor-command.xmlを配置しないといけません。最低でも提供側が定義ファイルに記述する内容をルートパッケージのJavaDocなどに記載したり、手引きに書いておかないと、何をどうしたら良いのかわかりません*6。解消案としては、基本ライブラリのProcessorCommandManagerにてxmlからコマンドクラスのパス(文字列)を取得しているので、ハードコーディングをするということが挙げられるでしょうか。今回はコマンド作成と登録と起動をメインに整理しました。次回はテストについて投稿したいと思っています。説明に使用するテストコードはすでに今回のプロジェクト内に入っているものを使う予定です。追記2017/8/19ブログ記載時の記述に一致するブランチを作成してリンクを修正。コードが生成されているのにクラスが参照できなくて「何でだ!!」と頭を抱える*5:本記事を上から順番に実施していたら出来ていると思います*6:このあたりを良い感じにできれば良かったのですがクラスローダー周りの実装力が無かったため断念しました。対応したいと思っていますが、とりあえず作ろうと思っているものを一通り作ってから改めて取り組もうと思っています。(4)はてなブログをはじめよう!vermeer-1977さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。