ANT十五大最佳實踐(轉)

ANT十五大最佳實踐

在Ant出現之前，建構和部署 Java應用需要使用包括特定平台的腳本、Make檔案、各種版本的IDE甚至手工操作的“大雜燴”。現在，幾乎所有的開源Java項目都在使用Ant， 大多數公司的内部項目也在使用Ant。Ant在這些項目中的廣泛使用自然導緻了讀者對一整套Ant最佳實踐的迫切需求。

本文總結了我喜愛 的Ant技巧或最佳實踐，多數是從我親身經曆的項目錯誤或我聽說的其他人經曆的 “恐怖”故事中得到靈感的。比如，有人告訴我有個項目把XDoclet 生成的代碼放入帶有鎖定檔案功能的版本控制工具中。當開發者修改源代碼時，他必須記住手工檢出（Check out）并鎖定所有将要重新生成的檔案。然後，手工運作代碼生成器，隻到這時他才能夠讓Ant編譯代碼，這一方法還存在如下一些問題：

生成的代碼無法存儲在版本控制系統中。

Ant（本案例中是Xdoclet）應該自動确定下一次建構涉及的源檔案，而不應由程式員手工确定。

Ant的建構檔案應該定義好正确的任務依賴關系，這樣程式員就不必為了完成建構而不得不按照特定順序調用任務。

當 我開始一個新項目時，我首先編寫Ant建構檔案。Ant檔案明确地定義建構的過程，并被團隊中的每個程式員使用。本文所列的技巧基于這樣的假定：Ant構 建檔案是一個必須仔細編寫的重要檔案，它應在版本控制系統中得到維護，并被定期進行重構。下面是我的十五大Ant最佳實踐。

1. 采用一緻的編碼規範

Ant使用者有的喜歡有的痛恨其建構檔案的XML文法。與其跳進這一令人迷惑的争論中，不如讓我們先看一些能保持XML建構檔案簡潔的方法。

首 先也是最重要的，花費時間格式化你的XML讓它看上去很清晰。不論XML是否美觀，Ant都可以工作。但是醜陋的XML很難令人讀懂。倘若你在任務之間留 出空行，有規則的縮進，每行文字不超過90列左右，那麼XML令人驚訝地易讀。再加上使用能夠高亮XML文法的優秀編輯器或IDE工具，你就不會有閱讀的 麻煩。

同樣，精選含意明确、容易讀懂的詞彙來命名任務和屬性。比如，dir.reports就比rpts好。特定的編碼規範并不重要，隻要拿出一套規範并堅持使用就行。

2. 将build.xml放在項目根目錄中

Ant 建構檔案build.xml可以放在任何位置，但是放在項目頂級目錄中可以保持項目簡潔。這是最常用的規範，開發者能夠在頂級目錄中找到預期的 build.xml。把建構檔案放在根目錄中，也能夠使人容易了解項目目錄樹中不同目錄之間的邏輯關系。以下是一個典型的項目目錄層次：

[root dir]

| build.xml

+--src

+--lib (包含第三方 JAR包)

+--build (由 build任務生成)

+--dist (由 build任務生成)

當build.xml在頂級目錄時，假設你處于項目某個子目錄中，隻要輸入：ant -find compile 指令，不需要改變工作目錄就能夠以指令行方式編譯代碼。參數-find告訴Ant尋找存在于上級目錄中的build.xml并執行。

3. 使用單一的建構檔案

有 人喜歡将一個大項目分解成幾個小的建構檔案，每個建構檔案分擔整個建構過程的一小部分工作。這确實是看法不同的問題，但是應該認識到，将建構檔案分割會增 加對整體建構過程的了解難度。要注意在單一建構檔案能夠清楚表現建構層次的情況下不要過工程化(over-engineer)。

即使你把項目劃分為多個建構檔案，也應使程式員能夠在項目根目錄下找到核心build.xml。盡管該檔案隻是将實際建構工作委派給下級建構檔案，也應保證該檔案可用。

4. 提供良好的幫助說明

應盡量使建構檔案自文檔化。增加任務描述是最簡單的方法。當你輸入ant -projecthelp時，你就可以看到帶有描述的任務清單。比如，你可以這樣定義任務：

<target name="compile"

description="Compiles code, output goes to the build dir.">

最簡單的規則是把所有你想讓程式員通過指令行就可以調用的任務都加上描述。對于一般用來執行中間處理過程的内部任務，比如生成代碼或建立輸出目錄等，就無法使用描述屬性。

這時，可以通過在建構檔案中加入XML注釋來處理。或者專門定義一個help任務，當程式員輸入ant help時來顯示詳細的使用說明。

<target name="help" description="Display detailed usage information">

<echo>Detailed help...</echo></target>

5. 提供清除任務

每個建構檔案都應包含一個清除任務，用來删除所有生成的檔案和目錄，使系統回到建構檔案執行前的初始狀态。執行清空任務後還存在的檔案都應處在版本控制系統的管理之下。比如：

<target name="clean"

description="Destroys all generated files and dirs.">

<delete dir="${dir.build}"/>

<delete dir="${dir.dist}"/>

</target>

除非是在産生整個系統版本的特殊任務中，否則不要自動調用clean任務。當程式員僅僅執行編譯任務或其他任務時，他們不需要建構檔案事先執行既令人讨厭又沒有必要的清空任務。要相信程式員能夠确定何時需要清空所有檔案。

6. 使用ANT管理任務從屬關系

假 設你的應用由Swing GUI元件、Web界面、EJB層和公共應用代碼組成。在大型系統中，你需要清晰地定義每個Java包屬于系統的哪一層。否則任何一點修改都要被迫重新編 譯成百上千個檔案。糟糕的任務從屬關系管理會導緻過度複雜而脆弱的系統。改變GUI面闆的設計不應造成Servlet和EJB的重編譯。

當系統變得龐大後，稍不注意就可能将依賴于用戶端的代碼引入到服務端。這是因為典型的IDE項目檔案編譯任何檔案都使用單一的classpath。而Ant能讓你更有效地控制建構活動。

設計你的Ant建構檔案編譯大型項目的步驟：首先，編譯公共應用代碼，将編譯結果打成JAR封包件。然後，編譯上一層的項目代碼，編譯時依靠第一步産生的JAR檔案。不斷重複這一過程，直到最高層的代碼編譯完成。

分步建構強化了任務從屬關系管理。如果你工作在底層Java架構上，偶然引用到高層的GUI模闆元件，這時代碼不需要編譯。這是由于建構檔案在編譯底層架構時在源路徑中沒有包含高層GUI面闆元件的代碼。

7. 定義并重用檔案路徑

如果檔案路徑在一個地方一次性集中定義，并在整個建構檔案中得到重用，那麼建構檔案更易于了解。以下是這樣做的一個例子：

<project name="sample" default="compile" basedir=".">

<path id="classpath.common">

<pathelement location="${jdom.jar.withpath}"/>

...etc </path>

<path id="classpath.client">

<pathelement location="${guistuff.jar.withpath}"/>

<pathelement location="${another.jar.withpath}"/>

<!-- reuse the common classpath -->

<path refid="classpath.common"/>

</path>

<target name="compile.common" depends="prepare">

<javac destdir="${dir.build}" srcdir="${dir.src}">

<classpath refid="classpath.common"/>

<include name="com/oreilly/common/**"/>

</javac>

</target>

</project>

當 項目不斷增長建構日益複雜時，這一技術越發展現出其價值。你可能需要為編譯不同層次的應用定義各自的檔案路徑，比如運作單元測試的、運作應用程式的、運作 Xdoclet的、生成JavaDocs的等等不同路徑。這種元件化路徑定義的方法比為每個任務單獨定義路徑要優越得多。否則，很容易丢失任務從屬關系的 軌迹。

8. 定義恰當的任務從屬關系

假設dist任務從屬于jar任務，那麼哪個任務從屬于compile任務哪個任務從屬于prepare任務呢？Ant建構檔案最終定義了任務的從屬關系圖，它必須被仔細地定義和維護。

應該定期檢查任務的從屬關系以保證建構工作得到正确執行。大的建構檔案随着時間推移趨向于增加更多的任務，是以到最後可能由于不必要的從屬關系導緻建構工作非常困難。比如，你可能發現在程式員隻需編譯一些沒有使用EJB的GUI代碼時又重新生成了EJB代碼。

以“優 化”的名義忽略任務的從屬關系是另一種常見的錯誤。這種錯誤迫使程式員為了得到恰當的結果必須記住并按照特定的順序調用一串任務。更好的做法是：提供描述 清晰的公共任務，這些任務包含正确的任務從屬關系；另外提供一套“專家”任務讓你能夠手工執行個别的建構步驟，這些任務不提供完整的建構過程，但是讓那些 專家使用者在快速而惱人的編碼期間能夠跳過某些步驟。

9.使用屬性

任何需要配置或可能發生變化的資訊都應作為Ant屬性定義下來。對于在建構檔案中多次出現的值也同樣處理。屬性既可以在建構檔案頭部定義，也可以為了更好的靈活性而在單獨的屬性檔案中定義。以下是在建構檔案中定義屬性的樣式：

<project name="sample" default="compile" basedir=".">

<property name="dir.build" value="build"/>

<property name="dir.src" value="src"/>

<property name="jdom.home" value="../java-tools/jdom-b8"/>

<property name="jdom.jar" value="jdom.jar"/>

<property name="jdom.jar.withpath"

value="${jdom.home}/build/${jdom.jar}"/>

etc...

</project>

或者你可以使用屬性檔案：

<project name="sample" default="compile" basedir=".">

<property file="sample.properties"/>

etc...

</project>

在屬性檔案 sample.properties中:

dir.build=build

dir.src=src

jdom.home=../java-tools/jdom-b8

jdom.jar=jdom.jarjdom.jar.withpath=${jdom.home}/build/${jdom.jar}

用一個獨立的檔案定義屬性是有好處的，它可以清晰地定義建構中的可配置部分。另外，在開發者工作在不同作業系統的情況下，你可以在不同的平台上提供該檔案的不同版本。

10. 保持建構過程獨立

為 了最大限度的擴充性，不要應用外部路徑和庫檔案。最重要的是不要依賴于程式員的CLASSPATH設定。取而代之的是，在建構檔案中使用相對路徑并定義自 己的路徑。如果你引用了絕對路徑如C:/java/tools，其他開發者未必使用與你相同的目錄結構，是以就無法使用你的建構檔案。

如果你部署開放源碼項目，應該提供包含編譯代碼所需的所有JAR檔案的發行版本。當然，這是在遵守許可協定的基礎上。對于内部項目，相關的JAR檔案都應在版本控制系統的管理中，并撿出（check out）到大家都知道的位置。

當你必須引用外部路徑時，應将路徑定義為屬性。使程式員能夠用适合他們自己的機器環境的參數重載這些屬性。你也可以使用以下文法引用環境變量：

<property environment="env"/>

<property name="dir.jboss" value="${env.JBOSS_HOME}"/>

11. 使用版本控制系統

建構檔案是一個重要的制品，應該像代碼一樣進行版本控制。當你标記你的代碼時，也應用同樣的标簽标記建構檔案。這樣當你需要回溯到舊版本并進行建構時，能夠使用相應版本的建構檔案。

除建構檔案之外，你還應在版本控制中維護第三方JAR檔案。同樣，這使你能夠重新建構舊版本的軟體。這也能夠更容易保證所有開發者擁有一緻的JAR檔案，因為他們都是同建構檔案一起從版本控制系統中撿出的。

通常應避免在版本控制系統中存放建構成果。倘若你的源代碼很好地得到了版本控制，那麼通過建構過程你能夠重新生成任何版本的産品。

12. 把Ant作為“最小公分母”

假設你的開發團隊使用IDE工具，當程式員通過點選圖示就能夠建構整個應用時為什麼還要為Ant而煩惱呢？

IDE 的問題是一個關于團隊一緻性和重制性的問題。幾乎所有的IDE設計初衷都是為了提高程式員的個人生産率，而不是開發團隊的持續建構。典型的IDE要求每個 程式員定義自己的項目檔案。程式員可能擁有不同的目錄結構，可能使用不同版本的庫檔案，還可能工作在不同的平台上。這将導緻出現這種情況：在Bob那裡運 行良好的代碼，到Sally那裡就無法運作。

不管你的開發團隊使用何種IDE，一定要建立所有程式員都能夠使用的Ant建構檔案。要建立 一個程式員在将新代碼送出版本控制系統前必須執行Ant建構檔案的規則。這将確定代碼是經過同一個Ant建構檔案建構的。當出現問題時，要使用項目标準的 Ant建構檔案，而不是通過某個IDE來執行一個幹淨的建構。

程式員可以自由選擇任何他們習慣使用的IDE工具或編輯器。但是Ant應作為公共基線以保證代碼永遠是可建構的。

13. 使用zipfileset屬性

人們經常使用Ant産生WAR、JAR、ZIP和 EAR檔案。這些檔案通常都要求有一個特定的内部目錄結構，但其往往與你的源代碼和編譯環境的目錄結構不比對。

一個最常用的方法是寫一個Ant任務，按照期望的目錄結構把一大堆檔案拷貝到臨時目錄中，然後生成壓縮檔案。這不是最有效的方法。使用zipfileset屬性是更好的解決方案。它讓你從任何位置選擇檔案，然後把它們按照不同目錄結構放進壓縮檔案中。以下是一個例子：

<ear earfile="${dir.dist.server}/payroll.ear"

appxml="${dir.resources}/application.xml">

<fileset dir="${dir.build}" includes="commonServer.jar"/>

<fileset dir="${dir.build}">

<include name="payroll-ejb.jar"/>

</fileset>

<zipfileset dir="${dir.build}" prefix="lib">

<include name="hr.jar"/>

<include name="billing.jar"/>

</zipfileset>

<fileset dir=".">

<include name="lib/jdom.jar"/>

<include name="lib/log4j.jar"/>

<include name="lib/ojdbc14.jar"/>

</fileset>

<zipfileset dir="${dir.generated.src}" prefix="META-INF">

<include name="jboss-app.xml"/>

</zipfileset>

</ear>

在這個例子中，所有JAR檔案都放在EAR檔案包的lib目錄中。hr.jar和billing.jar是從建構目錄拷貝過來的。是以我們使用zipfileset屬性把它們移動到EAR檔案包内部的lib目錄。prefix屬性指定了其在EAR檔案中的目标路徑。

14. 測試Clean任務

假設你的建構檔案中有clean和compile的任務，執行以下的測試。第一步，執行ant clean；第二步，執行ant compile；第三步，再執行ant compile。第三步應該不作任何事情。如果檔案再次被編譯，說明你的建構檔案有問題。

建構檔案應該隻在與輸出檔案相關聯的輸入檔案發生變化時執行任務。一個建構檔案在不必執行諸如編譯、拷貝或其他工作任務的時候執行這些任務是低效的。當項目規模增長時，即使是小的低效工作也會成為大的問題。

15. 避免特定平台的Ant封裝

不管什麼原因，有人喜歡用簡單的、名稱叫做compile之類的批檔案或腳本裝載他們的産品。當你去看腳本的内容你會發現以下内容：

ant compile

其實開發人員都很熟悉Ant，并且完全能夠自己鍵入ant compile。請不要僅僅為了調用Ant而使用特定平台的腳本。這隻會使其他人在首次使用你的腳本時增加學習和了解的煩擾。除此之外，你不可能提供适用于每個作業系統的腳本，這是真正煩擾其他使用者的地方。

總結

太多的公司依靠手工方法和特别程式來編譯代碼和生成軟體釋出版本。那些不使用Ant或類似工具定義建構過程的開發團隊，花費了太多的時間來捕捉代碼編譯過程中出現的問題：在某些開發者那裡編譯成功的代碼，到另一些開發者那裡卻失敗了。

生成并維護建構腳本不是一項富有魅力的工作，但卻是一項必需的工作。一個好的Ant建構檔案将使你能夠集中到更喜歡的工作——寫代碼中去！

參考

ANT的安裝配置(Jakarta ANT)

ANT十五大最佳實踐(轉)

Ant

AntGraph: Ant依賴性的可視化工具

Ant: The Definitive Guide, O'Reilly

Java Extreme Programming Cookbook, O'Reilly

《Ant權威指南》

UML類圖

UML的概念與使用

軟體配置管理系列--什麼是配置管理？

Subversion快速入門教程(SVN vs CVS)

Tomcat 配置技巧的精華詳解(Tomcat 配置)

ANT十五大最佳實踐(轉)

ANT的安裝配置(Jakarta ANT)

Rational ClearCase與MS Office的內建Rational ClearCase與MS Office的內建

ANT十五大最佳實踐