Antいいね

技術

最近Antの良さを実感している。

記述が冗長になりあんまりDRYじゃなくなりがちだけど、直感的なわかりやすさ、実績、情報量の多さなどで今もなおデファクトといっていいだろう。
同時期に出たStrutsは日本のSI業界では今でもある意味デファクトではあるだろうが、Antはおそらく今、そして今後も当分はデファクトであり続ける気がする。

＃そういえば最近１年半ぶりにAnt1.8がでましたね。

Mavenはフォルダ構成、依存性の管理など確かにメリットはあるけれど宣言的でDRYな記述形式はちょっとわかりにくい。それに品質面もちょっと怪しい。とくにエンコーディング周り。プラグインだけかもしれないけど。

あるパターンにマッチしたファイルをコピーするとかはAntではお手のものだ。こういった処理は開発以外でも意外と多い。RubyなりPythonなりでかけばいいじゃんという声も聞こえてきそうだが、僕はまだチャレンジしていない。

あとXMLであることが欠点であるかのように書かれているのを見ることがあるが僕個人はあまり気にしていない。

それにEclipseのAntエディタはなかなか使える。タグや属性の補完はもちろんdepends属性で指定したターゲットが無いと怒られるというようなバリデーションなんかもやってくれる。こういった環境面のメリットもあるので別にわざわざ別の言語で書こうという気にはあんまりならない。
Groovy, Scala, ClojureといったJVM言語だとまたちょっと違うかもしれないが。

ただしWindowsのEclipse3.5のAntはエンコーディングまわりの問題で処理が途中で止まってしまう可能性があるので実行する場合はコマンドプロンプトのほうが安全だろう。

またAntはコンパイルやjar作成以外にもDBのテーブル作成もsqlタスクでできる。この延長線上にはDBFluteやS2JDBC-Genがあると思うが（この系譜にはTorqueやRailsも入ると思う）、これだけAntでいろいろできるならもうAntでいいじゃんって思う。

もちろんMavenでもできるだろうけどAntのほうがわかりやすいよねっていう。

ただ最近はAnt知らないJava開発者も多いようでbuild.xmlが無いプロジェクトは結構あると思う。これだとビルド面倒だし、CIできないよね。

でも最近どうもEclipse+HudsonでCIできるらしい。つまりbuild.xml書かない。確かに依存性の情報なんかはEclipseの.classpathにあるわけだし、わざわざbuild.xml書くのはDRYじゃないよねっていうのはわかる。

ただビルドがIDEやCIに依存するのはどうなのかなーって個人的には思ってる。ビルドはビルドツールのみに依存しているべきなんじゃないかなと思っている。