Gradle在大型Java項目上的應用

標籤：

在Java構建工具的世界裡，先有了Ant，然後有了Maven。Maven的CoC[1]、依賴管理以及項目構建規則重用性等特點，讓Maven 幾乎成為Java構建工具的事實標準。然而，冗餘的依賴管理配置、複雜並且難以擴充的構建生命週期，都成為使用Maven的困擾。

Gradle作為新的構建工具，獲得了2010 Springy大獎，併入圍了2011的Jax最佳Java技術發明獎。它是基於Groovy語言的構建工具，既保持了Maven的優點，又通過使用 Groovy定義的DSL[2]，克服了 Maven中使用XML繁冗以及不靈活等缺點。在Eugene Dvorkin撰寫的文章《最讓人激動的5個Java項目》中，他是這樣介紹Gradle的：

“工程自動化是軟體項目成功的必要條件，而且它應該實現起來簡單、易用、好玩。構建沒有千篇一律的方法，所以Gradle沒有死板的強加方法於我 們，儘管你會認為尋找和描述方法很重要，然而Gradle對於如何描述有著非常好的支援。我不認為工具能夠拯救我們，但是Gradle能給你所需要的自 由，你可以利用Gradle構建易描述的、可維護的、簡潔的、高效能項目”。

在最近半年裡，我在使用Gradle作為構建指令碼的大型Java項目上工作，更深切體會到Gradle在項目構建過程中是如此的簡單、易用。

1. 多Module的項目

Hibernate項目負責人Steve Ebersole在Hibernate將構建指令碼從Maven換成Gradle時，專門寫了一篇文章《Gradle: why?》， 文中提到Maven的一個缺點就是：Maven不支援多module的構建。在Micro-Service[3]架構風格流行的今天，在一個項目裡麵包含 多個Module已成為一種趨勢。Gradle天然支援多module，並且提供了很多手段來簡化構建指令碼。在Gradle中，一個模組就是它的一個子項 目（subproject），所以，我使用父項目來描述頂級項目，使用子項目來描述頂級項目下面的模組。

1.1 配置子項目

在多模組的項目中，Gradle遵循慣例優於配置 （Convention Over Configuration）原則。

在父項目的根目錄下尋找settings.gradle檔案，在該檔案中設定想要包括到項目構建中的子項目。在構建的初始化階段 （Initialization），Gradle會根據settings.gradle 檔案來判斷有哪些子項目被include到了構建中，並為每一個子項目初始化一個Project對象，在構建指令碼中通過project(‘:sub- project-name’)來引用子項目對應的Project對象。

通常，多模組項目的目錄結構要求將子模組放在父項目的根目錄下，但是如果有特殊的目錄結構，可以在settings.gradle檔案中配置。

我所在的項目包括：

• 一個描述核心業務的core模組
• 一個遺留的Enterprise Java Bean（enterprise-beans）模組
• 兩個提供不同服務的Web項目（cis-war和admin-war）
• 一個通過schema產生jaxb對象的jaxb項目以及一個用來用來打ear包的ear項目
• 一個用於存放項目設定檔相關的config子目錄。它不是子模組，所以 config不應該被加到項目的構建中去。

它們都放置在根項目目錄下。我們通過如下的settings.gradle來設定項目中的子項目：

include ‘core‘, ‘enterprise-beans‘, ‘cis-war‘, ‘admin-war‘, ‘jaxb‘, ‘ear‘

我們將需要加入到項目構建中的子項目配置在settings.gradle檔案中，而沒有加入不需要的config子目錄。

1.2 共用配置

在大型Java項目中，子項目之間必然具有相同的配置項。我們在編寫代碼時，要追求代碼重用和代碼整潔；而在編寫Gradle指令碼時，同樣需要保持代碼重用和代碼整潔。Gradle 提供了不同的方式使不同的項目能夠共用配置。

• allprojects：allprojects是父Project的一個屬性，該屬性會返回該Project對象以及其所有子項目。在父項目的 build.gradle指令碼裡，可以通過給allprojects傳一個包含配置資訊的閉包，來配置所有項目（包括父項目）的共同設定。通常可以在這裡 配置IDE的外掛程式，group和version等資訊，比如：

  allprojects {    apply plugin: ‘idea‘    }

  這樣就會給所有的項目（包括當前項目以及其子項目）應用上idea外掛程式。

• subprojects：subprojects和allprojects一樣，也是父Project的一個屬性，該屬性會返回所有子項目。在父 項目的build.gradle指令碼裡，給 subprojects傳一個包含配置資訊的閉包，可以配置所有子項目共有的設定，比如共同的外掛程式、repositories、依賴版本以及依賴配置：

  subprojects {    apply plugin: ‘java‘    repositories {        mavenCentral()    }    ext {          guavaVersion = ’14.0.1’          junitVersion = ‘4.10’    }     dependencies {        compile(                “com.google.guava:guava:${guavaVersion}”        )        testCompile(                “junit:junit:${junitVersion}”        )    }}

  這就會給所有子項目設定上java的外掛程式、使用mavenCentral作為 所有子項目的repository以及對Guava[4]和JUnit的項目依賴。此外，這裡還在ext裡配置依賴包的版本，方便以後升級依賴的版本。

• configure：在項目中，並不是所有的子項目都會具有相同的配置，但是會有部分子項目具有相同的配置，比如在我所在的項目裡除了cis- war和admin-war是web項目之外，其他子項目都不是。所以需要給這兩個子項目添加war外掛程式。Gradle的configure可以傳入子項 目數組，並為這些子項目設定相關配置。在我的項目中使用如下的配置：

  configure(subprojects.findAll {it.name.contains(‘war‘)}) {    apply plugin: ‘war‘    }

  configure需要傳入一個Project對象的數組，通過尋找所有項目名包含war的子項目，並為其設定war外掛程式。

1.3 獨享配置

在項目中，除了設定共同配置之外， 每個子項目還會有其專屬的配置。比如每個子項目具有不同的依賴以及每個子項目特殊的task等。Gradle提供了兩種方式來分別為每個子項目設定專屬的配置。

• 在父項目的build.gradle檔案中通過project(‘:sub-project-name’)來設定對應的子項目的配置。比如在子項目core需要Hibernate的依賴，可以在父項目的build.gradle檔案中添加如下的配置：

  project(‘:core’) {      ext{                   hibernateVersion = ‘4.2.1.Final’      }dependencies {     compile “org.hibernate:hibernate-core:${hibernateVersion}”}}

  注意這裡子項目名字前面有一個冒號（：）。 通過這種方式，指定對應的子項目，並對其進行配置。

• 我們還可以在每個子項目的目錄裡建立自己的構建指令碼。在上例中，可以在子項目core目錄下為其建立一個build.gradle檔案，並在該構建指令碼中配置core子項目所需的所有配置。例如，在該build.gradle檔案中添加如下配置：

   ext{       hibernateVersion = ‘4.2.1.Final’      }dependencies {     compile “org.hibernate:hibernate-core:${hibernateVersion}”}

根據我對Gradle的使用經驗，對於子項目少，配置簡單的小型項目，推薦使用第一種方式配置，這樣就可以把所有的配置資訊放在同一個 build.gradle檔案裡。例如我同事鄭曄的開源項目moco。它只有兩個子項目，因而就使用了第一種方式配置，在項目根目錄下的 build.gradle檔案中設定項目相關的配置資訊。但是，若是對於子項目多，並且配置複雜的大型項目，使用第二種方式對項目進行配置會更好。因為， 第二種配置方式將各個項目的配置分別放到單獨的build.gradle檔案中去，可以方便設定和管理每個子項目的配置資訊。

1.4 其他共用

在Gradle中，除了上面提到的配置資訊共用，還可以共用方法以及Task。可以在根目錄的build.gradle檔案中添加所有子項目都需要 的方法，在子項目的build.gradle檔案中調用在父項目build.gradle指令碼裡定義的方法。例如我定義了這樣一個方法，它可以從命令列中 擷取屬性，若沒有提供該屬性，則使用預設值：

def defaultProperty(propertyName, defaultValue) {    return hasProperty(propertyName) ? project[propertyName] : defaultValue}

注意，這段指令碼完全就是一段Groovy代碼，具有非常好的可讀性。

由於在父項目中定義了defaultProperty方法，因而在子項目的build.gradle檔案中，也可以調用該方法。

2. 環境的配置

為了方便地將應用部署到開發、測試以及產品等不同環境上， Gradle提供了幾種不同的方式為不同的環境打包，使得不同的環境可以使用不同的設定檔。此外，它還提供了簡單的方法，使得我們能夠便捷地初始化資料庫 。

2.1 Properties配置

要為不同的環境提供不一樣的配置資訊，Maven選擇使用profile，而Gradle則提供了兩種方法為構建指令碼提供Properties配置：

• 第一種方式是使用傳統的properties檔案， 然後在使用Gradle時，通過傳入不同的參數載入不同的properties檔案。例如，我們可以在項目中提供 development.properties、test.properties和production.properties。在項目運行時，使用 -Pprofile=development來指定載入開發環境的配置。構建指令碼中載入properties檔案的代碼如下：

  ext {    profile = project[‘profile‘]}def loadProperties(){    def props = new Properties()    new File("${rootProject.projectDir}/config/${profile}.properties")            .withInputStream {                stream -> props.load(stream)            }    props}

  在運行指令碼的時候，傳入的-Pprofile=development可以指定使用哪個運行環境的設定檔。代碼中使用了 project[‘profile‘]從命令列裡讀取-P傳入的參數，Gradle會去父項目根目錄下的config檔案夾中需找對應的 properties檔案。

• 另外一種方式就是使用Groovy的文法，定義可讀性更高的設定檔。比如可以在項目中定義config.groovy的設定檔，內容如下：

  environments {    development {        jdbc {            url = ‘development‘            user = ‘xxxx‘            password = ‘xxxx‘        }    }    test {        jdbc {            url = ‘test‘            user = ‘xxxx‘            password = ‘xxxx‘        }    }    production {        jdbc {            url = ‘production‘            user = ‘xxxx‘            password = ‘xxxx‘        }    }}

  這裡定義了三個環境下的不同資料庫配置，在構建指令碼中使用如下的代碼來載入：

  ext {    profile = project[‘profile‘]}def loadGroovy(){    def configFile = file(‘config.groovy‘)    new ConfigSlurper(profile).parse(configFile.toURL()).toProperties()}

  這裡在ConfigSlurper的建構函式裡傳入從命令列裡取到的-P的參數。調用loadGroovy方法就可以附加元件目根目錄下的config.groovy檔案，並作為一個Map返回，這樣就可以通過jdbc.url來擷取url的值。

從可讀性以及代碼整潔（設定檔也需要代碼整潔）而言，我推薦使用第二種方式來配置，因為這種方法具有清晰的結構。如上面的例子，就可以把資料庫相 關的資訊都放在jdbc這個大的節點下，而不用像properties檔案這樣的扁平結構。但是對於一些已經使用properties檔案來為不同環境提 供配置資訊的遺留項目裡，使用properties檔案也沒有問題。

2.2 替換

通過不同的方式載入不同環境的配置後，就需要把它們替換到有預留位置的設定檔中去。在設定檔中使用@[email protected]來標註要被替換的位置，比如在config檔案夾中有jdbc.properties檔案，其內容如下：

[email protected]@[email protected]@[email protected]@

在Gradle構建過程中，有一個processResources的Task，可以修改該Task的配置，讓其在構建過程中替換資源檔中的預留位置：

processResources {    from(sourceSets.main.resources.srcDirs) {        filter(org.apache.tools.ant.filters.ReplaceTokens,                tokens: loadGroovyConfig())    }}

上面這種做法用來處理子項目src/main/resources檔案夾下的資源檔，所以需要將這段代碼放在子項目的獨立設定檔裡。

在一些複雜的項目中，經常會把設定檔放置到一個目錄進行統一管理。比如在我所在的項目，就專門提供了一個config子目錄，裡面存放了所有的配 置資訊。在處理這些資源檔時， Gradle預設提供的processResources就不夠用了，我們需要在Gradle指令碼中定義一個Task去替換這些包含預留位置的設定檔，然 後讓package或者deploy的Task依賴這個Task。該Task的代碼如下：

task replace(type: Sync) {            def configHome = "${project.rootDir}/config"    from(configHome) {        include ‘**/*.properties‘        include ‘**/*.xml‘        filter org.apache.tools.ant.filters.ReplaceTokens, tokens: loadGroovyConfig()    }    into "${buildDir}/resources/main"}

這裡定義了一個Sync類型的Task，會將父項目的根目錄下的config檔案夾的所有properties和xml檔案使用從 loadGroovyConfig()方法中載入出來的配置替換，並將替換之後的檔案放到build檔案夾下的resource/main目錄中。再讓打 包的Task依賴這個Task，就會把替換之後的設定檔打到包中。

2.3 更複雜的情況

上面介紹了在項目中如何使用Gradle處理 properties和xml檔案中具有相同配置，但其中的一些值並不相同的情況 。然而，在有些項目中不同的環境配置之間變化的不僅是值，很有可能整個設定檔都不相同；那麼，使用上面替換的處理方式就無法滿足要求了。

在我所在的項目中，我們需要依賴一個外部的Web Service。在開發環境上，我們使用了Stub來類比和Web Service之間的互動，為開發環境提供測試資料，這些資料都放置在一個Spring的設定檔中；而在測試和產品環境上，又要使用對應的測試和產品環 境的Web Service。這時，開發、測試與產品環境的配置完全不同。對於這種複雜的情況，Gradle可以在構建過程中為不同的環境指定不同的資源檔夾，在不 同的資源檔夾中包含不同的設定檔。

例如，在我們項目的config目錄下包含了application檔案夾，定義了不同環境所需的不同設定檔，其目錄結構如所示：

在構建指令碼中，根據從命令列讀入的-P參數，使用不同的資源檔夾，其代碼如下：

sourceSets {    main {        resources {            srcDir "config/application/spring/${profile}",                         "config/application/properties/${profile}"        }    }}

這樣在打包的過程中，就可以使用-P傳入的參數的資源檔夾下面的properties和xml檔案作為項目的設定檔。

2.4 初始化資料庫

在項目開發過程中，為了方便為不同環境構建相同的資料庫及資料，我們通常需建立資料庫的表以及插入一些初始化資料。Gradle目前沒有提供相關的Task或者Plugin，但是我們可以自己建立Task去運行SQL來初始化各個環境上的資料庫。

前面也提到Gradle是Groovy定義的DSL，所以我們可以在Gradle中使用Groovy的代碼來執行SQL指令檔。在Gradle腳 本中，使用Groovy載入資料庫的Driver之後，就可以使用Groovy提供的Sql類去執行SQL來初始化資料庫了。代碼如下：

groovy.sql.Sql oracleSql = Sql.newInstance(props.getProperty(‘database.connection.url‘),                props.getProperty(‘database.userid‘),                props.getProperty(‘database.password‘),                props.getProperty(‘database.connection.driver‘))try {        new File(script).text.split(";").each {            logger.info it            oracleSql.execute(it)        }    } catch (Exception e) { }

這段代碼會初始化執行SQL的groovy.sql.Sql對象，然後按照分號（;）分割SQL指令檔裡的每一條SQL並執行。對於一些必須運行 成功的SQL檔案，可以在catch塊裡通過拋出異常來中止資料庫的初始化。需要注意的是需要將資料庫的Driver載入到ClassPath裡才可以正 確地執行。

因為在Gradle中包含了Ant，所以我們除了使用Groovy提供的API來執行SQL之外，還可以使用Ant的sql任務來執行SQL指令檔。但若非特殊情況，我並不推薦使用Ant任務，這部分內容與本文無關，這裡不再細述 。

3. 代碼品質

代碼品質是軟體開發品質的一部分，除了人工程式碼檢閱之外，在把代碼提交到程式碼程式庫之前，還應該使用自動檢查工具來自動檢查代碼，來保證項目的代碼品質。下面介紹一下Gradle提供的支援代碼檢查的外掛程式 。

3.1 CheckStyle

CheckStyle是SourceForge下的一個項目，提供了一個協助JAVA開發人員遵守某些編碼規範的工具。它能夠自動化代碼規範檢查過 程，從而使得開發人員從這項重要卻枯燥的任務中解脫出來。Gradle官方提供了CheckStyle的外掛程式，在Gradle的構建指令碼中只需要應用該插 件：

apply plugin: ‘checkstyle‘

預設情況下，該外掛程式會找/config/checkstyle/checkstyle.xml作為CheckStyle的設定檔，可以在checkstyle外掛程式的設定階段（Configuration） 設定CheckStyle的設定檔：

checkstyle{configFile = file(‘config/checkstyle/checkstyle-main.xml‘)}

還可以通過checkstyle設定CheckStyle外掛程式的其他配置。

3.2 FindBugs

FindBugs 是一個靜態分析工具，它檢查類或者 JAR 檔案，將位元組碼與一組缺陷模式進行對比以發現可能的問題。Gradle使用如下的代碼為項目的構建指令碼添加FindBugs的外掛程式：

apply plugin: ‘findbugs‘

同樣也可以在FindBugs的設定階段（Configuration）設定其相關的屬性，比如Report的輸出目錄、檢查哪些sourceSet等。

3.3 JDepend

在開發Java項目時經常會遇到關於包混亂的問題， JDepend工具可以協助你在開發過程中隨時跟蹤每個包的依賴性（引用/被引用），從而設計高維護性的架構，不論是在打包發布還是版本升級都會更加輕鬆。在構建指令碼中加入如下代碼即可：

apply plugin: ‘jdepend‘

3.4 PMD

PMD是一種開源分析Java代碼錯誤的工具。與其他分析工具不同的是，PMD通過靜態分析獲知代碼錯誤，即在不運行Java程式的情況下報告錯 誤。PMD附帶了許多可以直接使用的規則，利用這些規則可以找出Java來源程式的許多問題。此外，使用者還可以自己定義規則，檢查Java代碼是否符合某些 特定的編碼規範。在構建指令碼中加入如下代碼：

apply plugin: ‘pmd‘

3.5 小結

上面提到的幾種代碼檢查外掛程式apply到構建指令碼之後，可以運行：

gradle check

來執行代碼品質檢查。更詳細的資訊請查閱Gradle的官方文檔。運行結束後會在對應的項目目錄下的build檔案夾下產生report。

對於Gradle沒有提供的代碼檢查工具，我們可以有兩種選擇：第一就是自己實現一個Gradle外掛程式，第二就是調用Ant任務，讓Ant作為一個 媒介去調用在Ant中已經有的代碼檢查工具，比如測試覆蓋率的Cobertura。我們的項目使用了Ant來調用Cobertura，但是為了使用方便， 我們將它封裝為一個Gradle外掛程式，這樣就可以在不同的項目裡重用。

4. 依賴

幾乎每個Java項目都會用到開源架構。同時，對於具有多個子模組的項目來說，項目之間也會有所依賴。所以，管理項目中對開源架構和其他模組的依賴是每個項目必須面對的問題。同時，Gradle也使用Repository來管理依賴。

4.1 Jar包依賴管理

Maven提出了使用Repository來管理Jar包，Ant也提供了使用Ivy來管理jar包。Gradle提供了對所有這些Respository的支援，可以從Gradle的官方文檔上瞭解更詳細的資訊。

Gradle沿用Maven的依賴管理方法，通過groupId、name和version到配置的Repository裡尋找指定的Jar包。同 樣，它也提供了和Maven一樣的構建生命週期，compile、runtime、testCompile和testRuntime分別對應項目不同階段 的依賴。通過如下方式為構建指令碼指定依賴：

dependencies {    compile group: ‘org.hibernate‘, name: ‘hibernate-core‘, version: ‘3.6.7.Final‘    testCompile group:‘junit‘, name: ‘junit‘, version ‘4.11‘}

這裡分別指定group、name以及version，但是Gradle提供了一種更簡單的方式來指定依賴：

dependencies {    compile ‘org.hibernate:hibernate-core:3.6.7.Final‘    testCompile ‘junit:junit:4.11‘}

這樣比Maven使用XML來管理依賴簡單多了，但是還可以更簡單一點。實際上這裡的compile和testCompile是Groovy為 Gradle提供的方法，可以為其傳入多個參數，所以當compile有多個Jar包依賴的時候，可以同時指定到compile裡去，代碼如下：

compile(       ‘org.hibernate:hibernate-core:3.6.7.Final‘,            ‘org.springframework:spring-context:3.1.4.RELEASE‘)

另外，當在Respository無法找到Jar包時（如資料庫的driver），就可以將這些Jar包放在項目的一個子目錄中，然後讓專案管理依賴。例如，我們可以在項目的根目錄下建立一個lib檔案夾，用以存放這些Jar包。使用如下代碼可以將其添加到項目依賴中：

dependencies {    compile(       ‘org.hibernate:hibernate-core:3.6.7.Final‘,            ‘org.springframework:spring-context:3.1.4.RELEASE‘,       fileTree(dir: "${rootProject.projectDir}/lib", include: ‘*.jar‘))}

4.2 子項目之間的依賴

對於多模組的項目，項目中的某些模組需要依賴於其他模組，前面提到在初始化階段，Gradle為每個模組都建立了一個Project對象，並且可以 通過模組的名字引用到該對象。在配置模組之間的依賴時，使用這種方式可以告訴Gradle當前模組依賴了哪些子模組。例如，在我們的項目中，cis- war會依賴core子項目，就可以在cis-war的構建指令碼中加上如下代碼：

dependencies {    compile(       ‘org.hibernate:hibernate-core:3.6.7.Final‘,             project(‘:core‘))}

通過project(‘:core’)來引用core子項目，在構建cis-war時，Gradle會把core加到ClassPath中。

4.3 構建指令碼的依賴

除了項目需要依賴之外，構建指令碼本身也可以有自己的依賴。當使用一個非Gradle官方提供的外掛程式時，就需要在構建指令碼裡指定其依賴，當然還需要指定該外掛程式的Repository。在Gradle中，使用buildscript塊為構建指令碼配置依賴。

比如在項目中使用cucumber-JVM作為項目BDD工具，而Gradle官方沒有提供它的外掛程式，好在開源社區有人提供cucumber的外掛程式。在構建指令碼中添加如下代碼：

buildscript {    repositories {        mavenCentral()    }    dependencies {        classpath "gradle-cucumber-plugin:gradle-cucumber-plugin:0.2"    }}apply plugin: com.excella.gradle.cucumber.CucumberPlugin

5. 其他5.1 apply其他Gradle檔案

當一個項目很複雜的時候，Gradle指令碼也會很複雜，除了將子項目的配置移到對應項目的構建指令碼之外，還可以可以按照不同的功能將複雜的構建指令碼 拆分成小的構建指令碼，然後在build.gradle裡使用apply from，將這些小的構建指令碼引入到整體的構建指令碼中去。比如在一個項目中既使用了Jetty，又使用了Cargo外掛程式啟動JBoss，就可以把他們分別 提到jetty.gradle和jboss.gradle，然後在build.gradle裡使用如下的代碼將他們引入進來：

apply from: "jetty.gradle"apply from: "jboss.gradle"

5.2 project的目錄

在指令檔中，需要訪問項目中的各級目錄結構。Gradle為Project對象定義了一些屬性指向項目的根目錄，方便在指令碼中引用。

• rootDir：在子項目的指令檔中可以通過該屬性訪問到根項目路徑。
• rootProject：在子項目中，可以通過該屬性擷取父項目的Project對象。

5.3 使用Wrapper指定Gradle的版本

為了統一項目中Gradle的版本，可以在構建指令碼中通過定義一個wrapper的Task，並在該Task中指定Gradle的版本以及存放Gradle的位置。

task wrapper(type: Wrapper) {    gradleVersion = ‘1.0‘    archiveBase = ‘PROJECT‘    archivePath = ‘gradle/dists‘}

運行gradle wrapper， 就會在根項目目錄下建立一個wrapper的檔案夾，會包含wrapper的Jar包和properties檔案。之後就可以使用gradlew來運行 task。第一次使用gradlew執行task的時候，會在項目根目錄下的gradle/dists下下載你指定的Gradle版本 。這樣在項目構建的時候，就會使用該目錄下的Gradle，保證整個團隊使用了相同的Gradle版本。

5.4 使用gradle.properties檔案

Gradle構建指令碼會自動找同級目錄下的gradle.properties檔案，在這個檔案中可以定義一些property，以供構建指令碼使 用。例如，我們要使用的Repository需要提供使用者名稱和密碼，就可以將其配置在gradle.properties中。這樣，每個團隊成員都可以修 改該設定檔，卻不用上傳到程式碼程式庫中對團隊其他成員造成影響。可以使用如下的代碼定義：

username=userpassword=password

在構建指令碼中使用”${username} “就可以訪問該檔案中定義的相關值。

由於篇幅有限，本文只是我在一個大型Java項目上使用Gradle的部分經驗，並未涵蓋所有Gradle相關的知識，包括如何編寫Gradle外掛程式以及Gradle對其他語言的構建，讀者可以通過閱讀Gradle的官方文檔（比起其他開源軟體，Gradle的另一特點就是文檔詳細）來瞭解。另外，Gradle是基於Groovy的構建工具，在使用Gradle的時候也需要瞭解和使用Groovy。所以，在學習Gradle外掛程式的過程中，也能學會Groovy相關的用法，可謂一舉兩得。

參考文獻:

[1] CoC: http://en.wikipedia.org/wiki/Convention_over_configuration

[2] DSL: http://en.wikipedia.org/wiki/Domain-specific_language

[3] Micro Service Architecture: http://yobriefca.se/blog/2013/04/29/micro-service-architecture/

[4] Guava: https://code.google.com/p/guava-libraries/

Gradle在大型Java項目上的應用