Java構建系統Maven 1.0於三年前發布，並且已經在開源世界和行業內得到廣泛采用；其後，2.0新的發布卻並沒有得到同等的贊譽。與此同時，Ruby變得越來越流行，而且通 過像Rake這樣的工具證明，內部 DSL的概念是非常有效的。
另一方面，用通用語言編寫的DSL即可運行。通過計算機所能達到的計算限度的擴展能力，你還能獲得高級語言的簡便性。
隨 著時間的過去，完全新的構建系統已由Ruby寫成，比如Bake和Rant。還有些構件系統擴展了Rake，比如Raven，像Maven一樣它也支持外 部存儲。
在這些系統中有個新的加入者，Buildr，尤其致力於簡化Java構建。作者Assaf Arkin提倡建立能精簡XML化和過度工程化的解決方案，你可以在他的blog或者他收集的tumblr引證中找到相關證據。這就是 為什麼他試圖從他的項目中，比如Apache Ode，去掉Maven2的原因。
我 們很快給它起了個綽號叫“Maven不可靠原則”，雖然公平一點說，我們知道它並沒有什麼不可靠，或者只是懷疑這個構建是否會運行：它不會。 但最終，也許有一天我們獲得了足夠多的理由。測試案例停止運行。（……）總之，我們不得不做出選擇。是敏捷還是Maven，必須使用它們其中的一個。
Assaf曾想到回到Ant：
於是我們開始想像沒有Maven的幸福生活。也許我們應該轉回到Ant？即使它有那麼多缺點，但至少Ant構建可以運行。當 然，Ant是不可聲明的，而這是所有軟件開發者的聖杯所在。但錯誤地使用聲明性比任何套管程序（注：結構非常復雜的程 序）還要糟糕。
……最終還是選擇了Rake。
因此我們做到了，開始使用Rake。讓我給你說說我的遭遇。Rake被證明是個非常棒的選擇，它是個好的開始，但這並不是我們原 本所期望的。我們運行的典型Java應用由一些模塊組成，所有模塊都有相同的普通生命周期任務：編譯、測試、打包、部署。為每一個模塊一遍又一遍地編寫那 些代碼使得這並不比Ant好多少。我們有了一個更好的辦法。
傳奇（Saga）導致了Buildr 的誕生，它具有容易實現的目標（也就是處理XMLBeans），並允許你依據普通的Ruby代碼來完成基本的任務。性能可能是阻止Buildr得 到更廣泛采用的最後障礙，但“快速而猛烈的”Buildr證 明自己是能夠和Maven競爭的 。
我們正在構建相同的代碼，運行相同的測試，編譯相同的XMLBeans，創建相同 的Hibernate schemas，共享相同的遠程和本地數據存儲。所有的這些是想說明，它們是功能相當的黑盒。給它們相同的項目，他們就能產生相同的JAR、WAR和分發 文件等。
它能構建相同的項目，但腳本從52個泛濫的XML文件縮減到只剩一個腳本，縮減率達91%。但這還不是全 部，Buildr設法把構建時間減少了50%！即使是部分構建，Buildr執行也類似或好過Maven。
當然，我們不是在估 測原生的Ruby和純Java。我們在比較一種實現和另外一種實現，它們完成的是相同的任務，黑盒是相當的。這是一個真實的基准對比。
Assaf以一個非常好的總結結束了采訪：
Ruby可能會比較慢，但你通過它構建的應用可能非常非常快。
我們可以想像，看到Maven 和Buildr短兵相接是多麼有趣的事情。
這篇文檔目前僅限於RDoc和一個Apache Rakefile示例，但有個完整的指南正在編寫中。
Buildr 的詳細介紹：請點這裡
Buildr 的下載地址：請點這裡