緣由在於,Project和Task都擁有description屬性。而定義Task的閉包將delegate設置成了當前的Task。故假設直接使用description。此時打印的是showProjectProperties的description。而不是Project的,因此咱們需要顯式地指明project。有關delegate的不少其它知識,請參考本系列的這篇文章。java
Gradle還爲咱們提供了多種方法來本身定義Project的Property。git
(1)在build.gradle文件裏定義Property
在build.gradle文件裏向Project加入額外的Property時。咱們並不能直接定義,而是應該經過ext來定義。假設要加入一個名爲property1的Property,咱們應該:
ext.property1 = "this is property1"
另外。咱們也可以經過閉包的方式:
ext { property2 = "this is property2"}
在定義了Property後。使用這些Property時咱們則不需要ext,而是可以直接訪問:
task showProperties << {
println property1
println property2
}
其實,不論什麼實現了ExtensionAware接口的Gradle對象都可以經過這樣的方式來加入額外的Property,比方Task也實現了該接口。
(2)經過命令行參數定義Property
Gradle還提供了-P命令行參數來設置Property,比方:
task showCommandLieProperties << {
println property3
}
在運行「gradle showCommandLieProperties」時,終端輸出例如如下:
* What went wrong:Execution failed for task ':showCommandLieProperties'.> Could not find property 'property3' on task ':showCommandLieProperties'.
表示property3並無被定義。在調用gradle命令時,經過-P參數傳入該Property:
gradle -Pproperty3="this is property3" showCommandLieProperties
此時終端顯示:
:showCommandLiePropertiesthis is property3BUILD SUCCESSFUL
(3)經過JVM系統參數定義Property
咱們知道。在java中。咱們可以經過-D參數定義JVM的系統參數。而後在代碼中可以可以經過System.getProperty()進行獲取。github
在Gradle中。咱們也可以經過-D的方式向Project傳Property。僅僅是此時咱們需要遵循一些約定:每一個經過-D方式聲明的Property都需要以「org.gradle.project」爲前綴。對於上面的showCommandLieProperties。咱們也可以經過下面方式
設置property3:
gradle -Dorg.gradle.project.property3="this is another property3" showCommandLieProperties
(4)經過設置環境變量Property
咱們還可以經過環境變量設置的方式設置Project的Property。這樣的方式和(3)同樣,需要咱們遵循一些約定:在定義環境變量時,每一個Property都需要以「ORG_GRADLE_PROJECT_」爲前綴:
export ORG_GRADLE_PROJECT_property3="this is yet another property3"
在調用showCommandLieProperties時,咱們便不需要傳入命令行參數了:
gradle showCommandLieProperties
在筆者所工做的項目中。咱們的持續集成server即是經過這樣的方式爲Gradle設置Property的。 閉包