Ant 使得Java JARs打包變得簡單和可靠

2019-11-18 12:53:36

字體：大中小

來源：轉載

供稿：網友

對于開發人員，除了不兼容性經常發生之外，Ant版本1.2遵循版本1.1的所有規則，而版本2.0能夠完全與版本1.2匹配。由于開發版本的不斷改變而導致的項目進度混亂，系統bug蠶生，以及源碼知識庫破壞，開發隊伍很長一段時間以來都爭議著版本號與內部識別系統的關系，比如發布、修正、轉折點、建立號。這些只限于辦公室的討論很少見于數據表格，網站，以及CDs中。然而，相比于辦公室的版本號，他們的爭議往往顯得更加有用，尤其是當回答一個新的bug出現時提出的“這在這一版本號中有什么區別？”的問題的時候。
　　
　　不同版本系統的存在是因為其能夠指定Build工具中的發布標示。有些制作商對開發代碼做出嚴格的保密，開發人員必須記住每一種版本改變所需要更改的信息。其他工程依靠于一些由許多源碼治理系統支持的符號替換系統。另外，很多其他工程仍然需要手工地建立存檔文件內部的一些小的文本文件。
　　
　　然而，每一個版本都有自己的問題。開發人員通常會忘記增加Build數目──尤其是對“quick, little fixes”的分類，這樣會很有可能導致出現bug。源碼治理系統是基于文件，而且反映的只是簡單文件的版本信息。當JARs打包，優化，融合的時候可以去掉文本文件。
　　
　　使用發布標識符來打包的更好方法是依靠于使用Ant build系統提供的符號過濾器。當從一個地方復制文件到另一個地方時，Ant復制任務可以使用任意字符串替代形成@TEXT@的符號。使用這一特性和一些其他Ant build文件技巧，我們可以確保所有的JARs能夠具有一個發布號而獲得打包，從而可以避免開發過程中的很多麻煩。
　　
　　源文件
　　現在讓我們看一看我們范例程序的源文件，即MyApp.java ( Listing A)。
　　
　　Listing A
　　
　　public class MyApp {
　　
　　　　public static final String RELEASE = "@RELEASE@";
　　
　　　　public static final String APP_NAME = "MyApp";
　　
　　　　public static final String VERSION =　"1.0";
　　
　　public static String getVersionString() {
　　　　　　return APP_NAME + " " + VERSION + " ("
　　
　　　　　　　　+ System.get　　
　　　　　　　　+ ((("@REL" + "EASE@").equals(RELEASE))?"":("; " + RELEASE))
　　
　　　　　　　　+ ")";
　　
　　　　}
　　
　　public static void main(String[] args) {
　　　　　　System.out.println(getVersionString());
　　
　　　　}
　　
　　}
　　在這一類文件中，你可以看到一個靜態域和方法。第一個靜態域名為RELEASE,其具有一個“@RELEASE@”的值。這也就是我們等下使用Ant復制過濾器取代的符號。然而現在，我們只需要將其置為“@RELEASE@”。
　　
　　兩個靜態方法中的第一個為getVersionString()，只是簡單地連接了一些其他靜態域的值，然后有選擇性地添加RELEASE值，除非其值為字符串@RELEASE@。這種情況不需要添加RELEASE值，因為它包含很多無用的build識別信息。假如RELEASE在源文件編譯之前已經被更改，這一值就會被添加到返回的版本字符中。
　　
　　請注重到，我們所使用與RELEASE值相比較的常量字符被分成兩個字符串，這兩個字符串在編譯時被連接，這就防止Ant符號替代過濾器替代@RELEASE@常量。
　　
　　Build文件
　　現在，我們將注重力轉移到Build.xml文件(Listing B)。
　　
　　表B
　　
　　<project name="myapp" default="jar">
　　
　　
　　　<property name="sources" value="src"/>
　　
　　
　　　<property name="classes" value="classes"/>
　　
　　<target name="jar" depends="pre-jar,classes"
　　　　　description="build release jar">
　　
　　　　<jar destfile="jar/${ant.project.name}.jar">
　　
　　　　　<fileset dir="classes">
　　
　　　　　　<include name="**/*.class"/>
　　
　　　　　</fileset>
　　
　　　　</jar>
　　
　　　</target>
　　
　　<target name="pre-jar" depends="ensure-release">
　　　　<property name="srcdir" value="jar/src"/>
　　
　　　　<mkdir dir="${srcdir}"/>
　　
　　　　<copy todir="${srcdir}">
　　
　　　　　<fileset dir="${sources}">
　　
　　　　　　<include name="**/*.java"/>
　　
　　　　　</fileset>
　　
　　　　　<filterset>
　　
　　　　　　<filter token="RELEASE" value="${release}"/>
　　
　　　　　</filterset>
　　
　　　　</copy>
　　
　　　</target>
　　
　　<target name="ensure-release" unless="release">
　　　　<fail message="You must define -Drelease=<name>"/>
　　
　　　</target>
　　
　　<target name="classes" description="compile classes">
　　　　<property name="srcdir" value="${sources}"/>
　　
　　　　<mkdir dir="${classes}"/>
　　
　　　　<echo message="srcdir=${srcdir}"/>
　　
　　　　<javacdestdir="${classes}" srcdir="${srcdir}">
　　
　　　　</javac>
　　
　　　</target>
　　
　　<target name="clean" depends="tidy" description="delete all generated files">
　　　　<delete dir="jar" quiet="true"/>
　　
　　　</target>
　　
　　<target name="tidy" description="delete all intermediary files">
　　　　<delete dir="jar/src" quiet="true"/>
　　
　　　　<delete dir="classes" quiet="true"/>
　　
　　　</target>
　　
　　</project>
　　Build.xml文件采用了非普通的技巧，其中的一個目標是防止開發人員對每一次的編譯指定發布信息。絕大部分的編譯并非都需要發布，為了給每一測試編譯提供一個發布名稱，開發人員將通過使用一個固定的Build標識符的值來對他們的Builds過程進行腳本化。
　　
　　為了達到這一目的，我們將對象分離以建立類和任何的JARs。名為classes的類首先將其srcdir屬性設置為前一個定義好的sources屬性值，然后，當classes對象直接運行，使用編輯的Java sources文件將可以在scr目錄中查找到。開發人員編寫的源代碼在被編譯之前，答應使用IDE和其他程序，這就能夠從編譯錯誤信息中提取文件名然后可以在編輯程序中得以糾正。
　　
　　然而，當sources文件被編譯為包含在一個JAR的類時，我們不會將這些類編譯在scr目錄中。相反，我們必須復制這些文件，然后執行符號替代。源代碼目錄的建立和聲明都在pre-jar目標中執行。
　　
　　然后，pre-jar目標從scr目錄中復制源代碼層次到jar目錄之下。在復制過程中，一個過濾器通過release屬性的值取代字符@RELEASE@的所有具體值。在pre-jar對象中設置過濾源目錄之后，classes對象將設置srcdir的值。幸運的是，Ant的不答應屬性重新定義的規則防止了設置的值不會被覆蓋。
　　
　　pre-jar目標處理過濾過程，但它無法保證用于@RELEASE@替代符號的release屬性一定具有一個賦予值。這一過程可以通過ensure-release目標來檢查，假如沒有賦予值，就會跳出一個失敗信息以說明如何指定一個發布標識符。
　　
　　集中
　　pre-jar和ensure-release目標能夠自動地被相關jar目標處理。尤其是jar目標確保它的任務被處理之前，pre-jar和classes被運行。首先pre-jar調用ensure-release目標以校驗是否已經對發布標識符已經設置。結果是形成一個Build系統，這一系統能夠使用classes目標（開發人員每一天編譯和測試）運行。
　　
　　使用打包或非打包形式，缺省的Build標識符等，這些輪換構建方法都成為可能。現實中的Build過程通常會比較復雜，但是，只要能夠避免javac任務的復本出現，絕大部分的構建都會變得直接明了。

上一篇：ANT 十五大最佳實踐經典案例分析

下一篇：Java升級篇：ANT十五大最佳實踐詳解