こんにちは、懸田です。
>>>>> In [extremeprogramming-jp : No.01795]
>>> "Masaru Ishii" <mishii@....jp>さん wrote:
> こんにちは．石井です．
[...]
> やはりこの方法しかないんですか．
> Ant の build.xml を書いていて困ったのは，
> ・サフィックスルールが定義できない
> ・便利なマクロ $@ や $* が提供されてない
> でしょうか．特にサフィックスルールがないのは痛いです．
> ＃近いものとして，mapper タグがありますがこれは別物のようです．
> あと，DTDを作成するのにかなり手間取りました．
こちらは御覧になりました？
http://www.sdv.fr/pages/casa/arc/ant-dtd.zip
> > 今、パッケージ毎にbuild.xmlを作成し、topにマスターbuild.xmlを作成して
> > Antターゲットから利用しているのですが、思ったようにうまくいくまで時間
> > がかかりました。(これは私が未熟なだけかもしれませんが)
> パッケージ毎に build.xml は辛そうですね．Makefile で include を使った
> 方がまだ楽かも．
今検討しているのは以下のようなものです。
1. 必要な設定値をPropertyファイル(name=valueの書式)で外部に出す
2. AntとMakefileからPropertyファイルをincludeする
3. 全体ビルド、JavaDoc作成、テストはAntで行い、パッケージ階層は
Makefileにデフォルトルールだけ書いておく
一応、パッケージ単位のbuild.xmlは作成したので置いておくつもりでは
ありますが(^^;
[...]
> さらに追い討ちをかけますが^^;，JUnit のテスト結果をXMLやHTMLで出されて
> も僕はあまりメリットを感じません．なぜなら，
> ・ Unit Test は100% パスするのが当たり前
> ・ 失敗結果を HTML に出力されても，ソースにすぐジャンプできない
> からです（Emacs ならすぐジャンプできます）．
> 受け入れテストを Ant で行い，集計するのなら理解できますが，UnitTest の
> 結果を ファイルで出力されても僕としてはあまりうれしくないのです．
> ファウラーの記事に載っているマスタービルドの仕組みを採用しているところ
> はメリットがあるのかな．
私はcronで一定時間に自動アップデート、ビルド、テストを行う予定です。
もちろんUnitTestは100%通るのが基本ですが、
* プロジェクト全体でデグレードがないことを証明する
* パッケージ単位でのテストなどにも適用できる
* テスト結果が整形されて表示されていると嬉しい(^^)
ということで意味があると考えています。
今、お客さんからもう一つ追い討ちがありました。
「antにmake -nみたいなのないの？」
あるのかなぁ.....
ThoughtWorksのCruiseControlがちゃんと使えるともっと良いのですが。
(まだあまり見ていない...)
http://cruisecontrol.sourceforge.net/index.html
では。
--
Takeshi Kakeda
mailto:kakeda@....jp
mailto:kakeda@....jp