JRake

以前よりもJRubyが成熟してきたため、数多くの人がついにantをRakeに置き換えることで、ビルドスクリプトの世界を向上させるためのアクションを起こそうと考えています。

私の元同僚であるマット・フェメルがこのプロジェクトを本格的に開始しており、彼のFoemBlogで進捗状況を綴っています。マットは大多数の人よりも多くのビルドスクリプトを執筆しており、2000年頃に私たち2人はXMLベースのビルドファイルが最善の道だと考えて間違いを犯しました。現在2人とも、完全なスクリプト言語が必要だと考えています。

ビルドスクリプトには、宣言型品質と手続き型品質の両方が必要です。ビルドファイルの中核は、タスクとそれらの依存関係の定義です。これは宣言部分であり、Antやmakeなどのツールが優れている部分です。問題は、ビルドが複雑になるにつれてこれらの構造だけでは不十分になることです。条件ロジックが必要になり、特に独自の抽象化を定義する機能が必要になります（例については、私のRake記事を参照してください）。

Rakeの強みは、これら両方を提供できることです。タスクと依存関係を定義するためのシンプルな宣言構文を提供しますが、この構文は内部DomainSpecificLanguageであるため、Rubyの機能をシームレスに組み込むことができます。

JavaビルドにおけるRakeの大きな問題は、Java VMの起動を数多く回避するのが困難だったことです。JRakeはJava VM内で実行されるJRuby上で実行するため、この問題は解消されます。

ビルドにRakeを使用することについての反対意見として、習得しなければならない言語が1つ増えるというものがあります。この議論で見逃されている点は、ant自体が独自の言語であるという点です。XML準拠という事実は、さまざまなantタスクの仕組みやそれらの組み合わせを理解する必要がないという意味ではありません。もちろん、すでにantを習得している場合は、Rakeを習得するために余分な労力がかかります。しかし、どちらも習得していない場合、Rake + Rubyの方が習得が簡単であり、スクリプト言語には他の多くの利点があります（すべてのプログラマーは少なくとも1つのスクリプト言語を習得しておくべきだと私は考えています。スクリプト言語には利便性が高い多くの機能があるのです）。

Antには多くの投資がなされているため、しばらくは存在し続けるでしょう。しかし、私たちはRakeが未来に向けたより優れたソリューションであると考えています。