Pluginのテストを自動化するには(その6-2-2:後日談)
ビルドのできなかった理由javacコマンドの実行時に与えられるソースバージョン、ターゲットバージョンとして1.6を与えていなかったという罠。また、現在のプロパティの設定ではLinux環境でしか動かないようになっています。
これらのバージョンはbuild.propertiesに書きます。じゃぁ、build.xmlはどこにあるのかという疑問が浮かびますが、これはビルド開始時にEclipseのAntから自動生成されています。Linux環境でビルドしてみると/tmp/build/I.Build/にビルドした成果物が出力されますが、それとおんなじ階層にfeatureに対応したbuild.xmlが出力されています。
Pluginのテストを自動化するには(その6-2:ビルドの自動化)
ビルドに関しては自動化の目処がついたので、sourceforge.netにプロジェクトをコミットしました。まだコンパイルエラーが発生していて、実はPluginとして使えないけれど;-<
海外でもこのあたりの話が書かれているサイトが少ないのは、Eclipseは結構ドキュメントがしっかり書かれているせい?思ったよりも簡単に環境を構築できた。マップファイル形式ではPluginごとにビルドしたいリビジョン、パスを指定できるので、差分ビルドもできそうだけれど、svn-pde-buildは未対応。SCMからコードを取得するときに前回と同じリビジョンだったら取得しないようにAntのスクリプトを生成するクラスをいじれば対応できるんだろうな。いじれば。いじれば…。
anonymousでもsvn exportで取得できるので、ご興味があれば。
https://eclipse-study.svn.sourceforge.net/svnroot/eclipse-study/PercsProject/trunk/org.kompiro.percs.releng/
Pluginのテストを自動化するには(その6-1:どこまで自動化したいのか確認)
まだちょっとだけしかできません。へたれです。とりあえず今回の自動化で目標とするものについて触れておきます。これを見てみるとEquinox上で動くCIツールを作りたくなるなぁ。
最低限のレベル
- SCM(今回はSubversion)から落とすことができる
- 起動するとビルドができている
- 起動するとテストができている
- テスト結果がHTMLで出力できている
- ビルドが終わったら何らかの形で通知されている
目標レベル
- どこにもっていってもこのプロジェクトをダウンロードすればビルドできる
- ビルド結果が更新サイトへ自動でアップロードされている
妄想レベル
- ビルドプロジェクト自身を起動するとCIサーバーになる
- テスト結果などを見ることができる
- ビルド履歴がRSSで見られる
- HTTPハンドラがあって、それを呼ぶとビルドができる。
- SCMを監視して更新してたらビルドする(素直にCCとかContinusとかHudson使え)
妄想レベルまで達成できたら立派にEclipseFoundationにプロジェクトとして申請できるのではないかという気がする。そういうプロジェクト見かけたし。進んでるかどうかは定かじゃぁない。
今回はEclipse3.3.1のbasebuilderを落としてきました。同梱されているAntは1.7.0なので、ほとんどの作業はAnt任せにできます。OSGiアプリケーションのビルドに必須なタスクはPDEのプラグインプロジェクトとして既に導入されてるし、もしこれ以外にないタスクとかは拡張ポイントを定義したプラグインプロジェクトをbasebuilder/plugins/以下に突っ込めばもちろん動かせます。Subversion対応としてpde-svn-pluginをbasebuilderへ入れれば対応できるのはそのためです。
Pluginのテストを自動化するには(その6準備編:Eclipsepedia上の自動化資料)
調べてみるといろいろと見つかりますね。
Eclipsepedia:Release Engineering
このページを参考にしつつ、SpringIDEのビルドプロジェクトを修正していくことで自分のプラグインのビルドを自動化し、その後テストも自動化できそうですので、この週末挑戦してみます。今日はSpringIDEのビルド方法を読み進めているところで終了です。
SpringIDEのビルドではプラグインのビルドだけではなく、更新サイト用のプラグインの圧縮や、ビルド用のEclipseを自動でダウンロードし、ビルドに必要なプラグインのインストールも自動で行ってます。
例えば更新サイト用のプラグインの圧縮はこんな感じです。
java -Xmx256m -jar $ECLIPSELOCATION -application org.eclipse.update.core.siteOptimizer -jarProcessor -verbose -processAll -repack -pack -outputDir $STAGINGLOCATION $STAGINGLOCATION
プラグインはjarの中にjarを入れる構造をとるので、圧縮にpack200を使う方法らしいのですが、JDK1.5以上にのみ対応しているそうです。なので、JDK1.4未満のために通常のプラグインを用意しておく必要があります。
ビルドに必要なプラグインのインストールはこんな感じです。
java -cp $ECLIPSELOCATION org.eclipse.equinox.launcher.Main -application org.eclipse.update.core.standaloneUpdate -command install -featureId $1 -version $version -from $2
この辺のコマンドはすべてSpringIDEのビルドプロジェクト内のbuild.shに書かれているのでこれを取っ掛かりにしています。
Pluginのテストを自動化するには(その5番外編:有名どころのビルド自動化を探ってみる)
Subversionに対応したリポジトリからプラグインのリソースを引っ張ってきて自動ビルドをしているプロジェクトがないか探ってみたらありました。SpringIDEです。
現在リポジトリを移動中だそうで、Tracとうまく同期がとれていない状態ですが、以下のSubversionコマンドを打つと自動ビルド用のプロジェクトをチェックアウトできます。
svn co https://anonsvn.springframework.org/svn/spring-ide/trunk/org.springframework.ide.eclipse.releng
SpringIDEの自動ビルド環境にはorg.eclipse.releng.basebuilderも同梱されています。この同梱されている環境ではSubversion用のマップファイルにも対応しています。ただ、残念ながらこのbasebuilderはEclipse3.2の時のものなので、3.3用のプラグインをビルドするときにはもしかすると何かが必要かも分かりません。(現在調査中)
この辺を調べ尽くしてから自分のプラグインのビルドを自動化してみて、手順をまとめて報告するつもりです。
Pluginのテストを自動化するには(その5-2-2:Eclipseのビルドをしてみた:補足)
componentの指定の方法が分かりました。コマンドの中で
-Dcomponent=[指定したいコンポーネントのフルパスを書く]
を追加してください。Windowsだとフルパスを指定する必要はないかもわかりませんが、Linux環境だとフルパスを指定する必要がありました。コンポーネントを指定すると、CVSから関連するプラグイン・プロジェクトやフィーチャー・プロジェクトをダウンロードして、ビルドを始めます。
Eclipseの標準でがプラグイン・プロジェクトの関連はマップファイルに書き込みます。マップファイルの中はこんな感じです。
!****launcher, startup.jar plugin@org.eclipse.equinox.launcher=v20080114,:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse, fragment@org.eclipse.equinox.launcher.win32.win32.x86=v20080114,:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse,,org.eclipse.equinox.launcher/fragments/org.eclipse.equinox.launcher.win32.win32.x86
まだ中の形式について詳しく調べてませんが、『!*』で始まっている行はたぶんコメントです。で、『@』の前がそのプロジェクトがpluginか、fragmentか、はたまたfeatureなのか、『@』の後がプロジェクト(プラグイン)名、『=』の後がタグ名その後の『,』以降がCVSのリポジトリの設定だと思われます。(今度形式についてはきっちり調べます。)
現在サポートしているのはCVSのみです。不便ですが、SubversiveがEclipseのプロジェクトになったため、SubversionのサポートはGanymedeに含まれるかもしれません。
