用Gradle構建Java Play架構應用

標籤：

在LinkedIn，我們一直在評估最好的開發架構和工具來開發偉大的產品。11年的曆史中，我們使用過很多前端web架構-如Grails、Frontier（LinkedIn內部的web架構），最近是：Play！我們喜歡Play，並熱情地在公司內部推行起來。於是我們用Play進行了整合和擴充。現在我們正在評估哪個構建系統（build system，下同）更好用。

這篇文章介紹了用在Play中用Gradle來支援開發，及Gradle的目前狀態和它的初步特性的演化。我們希望Play社區提供更多反饋以協助Gradle類軟體的開發。能夠給Sbt和Gradle開發Play應用將提供更多的自由度和多樣性。

背景：代碼的組織

在LinkedIn，我們用代碼倉庫管理公用API和服務，每個這種倉庫我們給它取了個名叫 Multiproduct，每個Multiproduct通過獨立的Ivy來組織，預設的名稱是com.linedin。LinkedIn的部分代碼已經開源了，如databus。

用Multiproducts來組織代碼的結果是，它們都是多工程的構結構，每個Multiproduct有10個或100個工程，同時每個工程又有多個 構件（artifacts，下同）。

在LinkedIn，我們的Play應用在classpath路徑下有超過500個jar包，這意味著全依賴解析的話需要處理至少500個節點。但依賴解析重度依賴於衝突解決的規則（導致效率低）。我們不在構件（如jar）層解析版本，而是在Multiproduct（或Ivy組織）層處理，這樣可以保證同一個Multiproduct內全部構件版本是一致的。

例如，工具類util Multiproduct，我們有3個不同的模組，com.linkedin.util:foo, com.linkedin.util:bar, com.linkedin.util:baz。每一個模組可能有一個或多個構件，一般的衝突解決辦法 可保證所有模組只有一個版本，但不同模組間的版本（本例中的"com.linkedin.tuil:foo", "com.linkedin.util:bar", and "com.linkedin.util, baz"）仍可能不同。我們自訂依賴處理器將確保同一個Multiproduct中的所有構件是同一個版本。

使用SBT的擴充性挑戰

Play預設的構建工具是SBT，Play與SBT在技術上是解耦了，但底層仍有很多未分離。當我們開始開發Play應用時，很快就遇到了SBT擴充性方面的挑戰，而且很依賴於Apache Ivy庫，某個應用的依賴解析需要5-10分鐘，一個架構工程呢，就要花30分鐘以上。

過去一年，LinkedIn跟Typesafe合作來提升SBT的擴充性，現在還在繼續，然而，同時，我們感覺到評估下其它的構建工具也是值得的。

Play與Gradle的整合

LinkedIn已經使用Gradle有3.5年了，到處都有gradle的影子，從小項目到單個Multi-product構建了近4000個工程，而且2015年的gradle還帶了許多激動人心的新特性。

除了以上，我們相信整合兩者對雙方都很有價值，跟Gradleware 一起我們開始研究如果讓它成為現實。2015年上半年，我們將注重整合的實現和測試，已經完成 3個裡程碑 了。

裡程碑1：用Gradle來開發一個Play應用。

讓Gradle與Play的插上電，開發人員可以用gradle構建一個具有Play全部特性的應用。

特性包括：

• 編譯Java和Scala源碼
  

• 編譯路由
  

• 編譯模板
  

• 編譯資源/設定檔
  

• 支援CoffeeScript, LESS/CSS, JavaScript

使用這個構建管道，Play應用可以用 gradle run 或 gradle start 啟動，或用 gradle stage 或 gradle dist 來發布。

有了這個能力我們就可以全面的測試Play的構建系統的效能和可擴充性了。

提示：這個裡程碑裡 持續模式（continuous mode） 和 熱載入（hot reload） 不支援。

裡程碑2：持續模式 和 熱載入

開發應用時能夠熱載入將是最令人愉快的Play特性。

自動化之前手工打包處理是一個偉大的主意，我們熱切希望能加到gradle裡。裡程碑2將介紹Gradle的“觀察者”模式，這跟SBT的持續模式（continuous mode）相同：gradle --watch run。

Play也可以當瀏覽器重新整理時自動重新構建，這是通過Play的BuildLink介面實現的，這個裡程碑將包含這個特性。

裡程碑3：變為現實

如果你熟悉Play可能已經注意到了缺失了一個嚴重的特性：Scala的互動功能 REPL！別急....這是裡程碑3的一部分，將允許你在控制台與類（classes）進行互動。

還有文檔，跟Specs2 整合了, 還有Scala的代碼也優雅的整合了。為了讓這些一起啟動起，你需要一個適當的Gradle基礎平台，就像你之前用activator一樣。

想瞭解更多？可以參考這裡。

初試 裡程碑1

該裡程碑的特性已經完成了，你可以下載最新版本嘗試下。下載包裡有二進位檔案、原始碼檔案和例子工程。解壓縮後加“bin”路徑加到你的環境變數。

Play的例子在 “samples/play” 目錄。

基本的

基本例子 build.gradle 檔案示範了Play外掛程式聲明及倉庫需求配置，依賴塊展示了如果定義第3方類庫，‘play‘ 配置提供了統和運行依賴，‘playTest‘ 提供了測試時的依賴定義。

進階的

進階例子 build.gradle 展示了如果配置成 Play/Scala 版本。

Multiproduct：

這是標準的Gradle multiproject 構建配置，根目錄包含了Play主應用，3個子模組在modules目錄下，admin和user子模組在在各自檔案夾裡，utile是一個java 類庫。settings.gradle 檔案串連了3個子工程，主工程build.gradle 描述了3個子模組各自的依賴。

你可以嘗試執行以下任務：

• gradle :assemble :構建 jar 和 assets

• gradle :runPlayBinary : 構建和運行應用在開發人員模式

• gradle :check : 執行測試案例

• gradle :stage : 構建和發布 image, 與啟動指令碼一起

預覽版本的效能

我們比較了Gradle和Activator（sbt）兩個方式的構建時間。

用來比較的工程

• Basic - 一個簡單的Play工程, play-scala模板設為activator.

• Multiproject - 構建在gradle的multiproject的Play例子工程，a multiproject build based on the gradle’s，例3也是util的子工程.

測試方法

• 所有依賴庫已經下載到本地gradle和ivy緩衝裡.

• 測試工作"dist "將產生最終發布tar包，將測試整個構建和發布流程，同時圍繞著依賴解析、編譯、打包執行。

• Gradle是串列執行，在 vanilla sbt 使用時 configure-on-demand 和 daemon 啟用 .

• Clean-build: 展示了從一個乾淨狀態的完整打包處理流程。

• No change: 沒作任務改變返回 “dist” .用來測試構建配置和更新有多快。

• Incremental:改了一行讓根Play工程依賴了java或scale子工程來類比典型的流程。

測試結果

從以上可以看出，Gradle構建除了1個差一些外都勝出了，不管是沒有或小修改都很好，這正是我們期望的。http://app.csq.im

基本依賴解析效能評估

我們對依賴解析的效能更加感覺興趣，所以我們只想比較解析所有依賴要花多久，對 activator/sbt

備忘
1.Gradle的“依賴”解析任務不僅僅是解決依賴問題，實際上還列印出了4個子工程的依賴樹
2.Gradle的依賴解析處理時間是通過內建的分析工具報告的

從上面的結果可以輕易的得出結論 Gradle的原生依賴解析引擎快過activator/sbt使用的 Ivy引擎 10倍以上。那就是我們為何將java工程構建在Gradle之上的原因。

我們仍努力將之前需要5-10分鐘的的activator/sbt項目用Gradle進行重構，我們期望更好的結果！

用Gradle構建Java Play架構應用