MavenはAntとは別物だと私は思うので、こういう問いかけが成り立つかどうか疑問です。とはいえ、じゃあどう言えばいいのかと言われると、そういうしかないのが、Mavenの痛いところです。Antのadaptorとしての方向ではなく、Antのプラグインとして頑張れるだけ頑張って実装したほうがマーケティング的には成功だったかもしれません。でも、プラグインの開発にわざわざJavaを使いたくないのでスクリプト化する方向をとり、Jelly(XMLスクリプト言語)-Mavenとしたのでしょう。
Jellyはすごいのですが、こういう方法を見るにつけ、Javaの進化の袋小路が気になります。Javaはheavyなので、便利にしようといろいろツールを産み出すのですが、ツールがツールを生み、逆に、ツールに縛られて、さらにJavaがheavyになっている気がします。別にRubyなんかで書いてたっていいと思うのです。なんか、Javaを使うことそれ自体がフレームワークと化しているようで、もっと自由なプログラミングや発想がある気がします。進化論的にいえば、ある環境にきわめて都合よく進化した個体がJavaによる開発です。この環境が続けば最強なのですが、大きな環境変化には意外と弱いかもしれません。
Mavenで便利になる部分についてはAntよりも圧倒的に便利です。圧倒的にはまる部分もあるので、広くは勧めにくいのですが。
Antはmakeにたとえられるのはよいでしょう。Mavenをたとえるのは難しく、MavenはMavenなのですが、私の感覚では、(Debianの)パッケージングに近いです。フォーマットどおりに書いておけばいろいろ便利で、その便利さを支えるプラグイン(debhelper)もあり、配布可能な状態にすぐにできます(repository、自動up/download、ホームページ作成)。
J2EEをMavenで設定するのは面倒ですが、J2EEのパッケージングはそもそも面倒なので(JBossでの悩ましさでおなじみですが、J2EEクラスのClass Loadingの方法がきちんと仕様化されていないのもいけない)、Mavenに起因するのかは微妙なところです。ただ、POMでできること(POMに組み込めること)はもっとあるので、さらなる拡張を望みます。たとえば、dependencyのdependencyを追いかけたり、ビルド時とパッケージングのdependencyを区別したり、J2EEの構造を指定できたり(multiproject/reactorは対処療法であり、根本解決ではない気がする)、とか。MLでいろいろ議論されているので、1.0リリース後、機能拡張されていくことでしょう。
Debian単位でAppServerになれば、それでよいと思います。apt-get install j2ee-appserverとして、/usr/share/javaにあるライブラリはすべて読む。もしくは、/etc/j2ee-server.confで設定する。/var/www以下のServletやJSPはコンテンツとして実行する。それって、Apacheか(^^;。こういう設定はJ2EE的にはできるのですが、そういう文化になっていないのは、なぜかな。
どうせOSを見せたくないなら、Zopeのように徹底すると方向が分かりやすい。最近のZopeの動向を詳しく見てないので嘘をいっているかもしれませんが、Zopeがその斬新なアイデアほどには流行らないのは、Zopeの開発体勢にあるのかもしれません。ZopeはOSを作っているに等しいのだから、変更には注意深くならなくてはいけません。Linuxで、glibcのAPIやFile Systemが頻繁に変わったら使ってられません。まあ、新しいので変更せざるを得ないのは仕方がないので、ずっと先のバージョンで爆発するかもと、長い長い目で見ることにしました。
というわけで、Apacheくらい落としどころが使いやすいのかな。
書きすすめたら、徒然になってしまいました。
いい映画でした。さすが、夫婦で応援しているトム・クルーズ。見るまでは、えせ日本になっているのではと危惧していたのですが、いやいや、昔の日本がよく描けています。キスシーンが画竜点睛を欠いて99点。こう表現しないとアメリカ人には分からないので仕方ないですが、それ以外はなかなか頑張ったので、最後まで貫いて欲しかった。Ken Watanabeも名演です。
JBoss3.2.3が公式にアナウンスされました。