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時，你就可以看到帶有描述的任務清單。比如，你可以這樣定義任務：

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

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

<target name="help" description="Display detailed usage information">
<echo>Detailed help...</echo></target>

5. 提供清除任務

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

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

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

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

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

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

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

7. 定義並重用檔案路徑

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

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

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

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

應該定期檢查任務的從屬關係以保證構建工作得到正確執行。大的構建檔案隨著時間推移趨向於增加更多的任務，所以到最後可能由於不必要的從屬關係導致構建工作非常困難。比如，你可能發現在程式設計師只需編譯一些沒有使用EJB的GUI程式碼時又重新生成了EJB程式碼。

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

9.使用屬性

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

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

在屬性檔案 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）到大家都知道的位置。

當你必須引用外部路徑時，應將路徑定義為屬性。使程式設計師能夠用適合他們自己的機器環境的引數過載這些屬性。你也可以使用以下語法引用環境變數：

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屬性是更好的解決方案。它讓你從任何位置選擇檔案，然後把它們按照不同目錄結構放進壓縮檔案中。以下是一個例子：

在這個例子中，所有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構建檔案將使你能夠集中到更喜歡的工作——寫程式碼中去！