この記事はブログに投稿されたものの転載です。
Atlassianプラグイン開発プラットホームでは様々なJavaフレームワークが利用されており、中には一般的なものも幾つか含まれています。今回それらのフレームワークを用いてAtlassianライクなWebフレームワークを作成したのでご紹介します。作品はGitHubに上げています。
目的
このWebフレームワークの狙いは「一般的なJavaフレームワークをAtlassianプラグイン開発プラットホームから切り離すこと」にあります。それにより以下の効果を図っています。
- Atlassianプラグイン開発に精通していないメンバーにも作業分担できる。
- 外注する場合にもこちら側で指定するフレームワークのサンプルとして提供することができる。
- Atlassianプラグイン開発で培ったノウハウを活用できる。（特に私にとっては^^）
Javaフレームワーク
このWebフレームワークは以下のフレームワークより構成されています。
- Java EE (Beans, JSP, Servlet)
- Spring DI
- Jersey
- ActiveObjects
- Velocity
Java EE
Java EEのBeans, JSP, ServletはMVCモデルを実現するために利用しています。Atlassianプラグイン開発プラットホームではMVCモデルとしてWebWorkというJavaフレームワークも使用していますが、製品毎でバージョンが異なること（JIRAでは1.x、その他は2.x）、そしてアクション作成時には独自の抽象クラスを継承する必要があることから除外しています。ちなみに、このWebWorkはバージョン2.2からはStruts2へ統合されています。
Spring DI
SpringのDIはコンポーネントの依存性注入のため利用しています。コンポーネント定義でアノテーションを使わないのは、Atlassian Spring Scannerを利用せずにatlassian-plugin.xml（SpringのapplicationContext.xmlに該当）で定義する方法を想定しているためです。多くのプラグインを見る限りではatlassian-plugin.xmlへ定義する方法が一般的なようで、私のプロジェクトでもこの方法を取り入れています。ただし、ServletやRESTリソース等のモジュールへの注入については仕様上の問題でAutowiredアノテーションを利用しています。
Jersey
JerseyはRESTfulなWebサービスを提供するために利用しています。Json形式によるデータのやり取りを専ら行うため、Jsonが利用できるように設定しています。Atlassianプラグイン開発では、既存画面の拡張性が乏しく、中でも画面操作をトリガーにしたデータ処理については全てREST APIを通じて行うしかありません。そのため、この機能の使用頻度も高く、Atlassianプラグイン開発プラットホームから切り離して開発できる意味は大きいかと思います。
ActiveObjects
ActiveObjectsをORMツールとして利用しています。ActiveObjectsではテーブル及びフィールド命名規則としてキャメルケースを採用していますが、Atlassianでは大文字のスネークケースを採用しています。そのため、当該フレームワークでもAtlassian仕様に合わせています。Atlassian仕様の名前変換器はnet.java.ao.atlassianパッケージ配下にあります。
Velocity
Velocityをテンプレートエンジンとして利用しています。モダンなシンタックスで記述できるため、個人的にはJSPよりもVelocityを愛用しています。AtlassianプラグインではWebWorkと組み合わせて利用するのが一般的ですが、先述の都合によりWebWorkは除外しているのでServlet内部で利用しています。
最後に
このフレームワークを利用することで、REST APIを通じたデータ処理についてはそのまま対応できそうです。ただし、イベントリスナーやワークフローなど需要の大きなモジュールを利用する開発では対応できないため、やはりメンバーがAtlassianプラグイン開発ができるよう教育した方が効率が良いような気もします。