企業(yè)應用的Ant模組編譯環(huán)境
作者：Les A. Hazlewood
06/22/2005
翻譯：tetsu版權聲明：可以任意轉載，轉載時(shí)請務(wù)必以超鏈接形式標明文章原始出處和作者信息及本聲明
英文原文地址:
http://www.onjava.com/pub/a/onjava/2005/06/22/modularant.html中文地址:
http://www.matrix.org.cn/resource/article/43/43716_Ant.html關(guān)鍵詞： Ant Compile
編譯環(huán)境對于今日的Java企業(yè)級應用程序來(lái)說(shuō)，越來(lái)越難于管理了。堆積如山的代碼，配置文件，以及對第三方的依賴(lài)（third-party dependencies）都使得管理編譯環(huán)境變得困難。
簡(jiǎn)而言之，我們勉強接受那種把所有的源代碼放在一個(gè)根目錄下，所有的配置文件放在另一個(gè)根目錄下，而第三方類(lèi)庫也這樣處理的做法。但是企業(yè)級編譯環(huán)境很少這么做。今日的企業(yè)級Java項目，在結構，功能，以及組織上都很復雜。它們通常都有大量的源代碼和支持資源（屬性文件，圖片，等等。編者注：原文為supporting artifacts，直譯為支持物件，但這里根據上下文意譯為支持資源較妥）要去管理。有這么多的東西去管理，當一個(gè)開(kāi)發(fā)團隊試圖去建立一個(gè)優(yōu)化的編譯方案時(shí)，他們常常感到困惑和挫敗。
如果，不管這個(gè)項目有多大，我們的編譯環(huán)境都能夠在統一的構架中簡(jiǎn)潔地處理我們所有的源代碼，事情是不是會(huì )變得好一些呢？本文將展示一個(gè)Ant編譯環(huán)境的例子，它來(lái)自我對多年來(lái)的多個(gè)項目的經(jīng)驗的修改。此時(shí)此地，它或許不是最好的方案，但是它的確經(jīng)歷了時(shí)間的考驗，也一定會(huì )幫助你建立并運行在大多數項目上，不管是大是小。
警告先就一些問(wèn)題說(shuō)明一下，這樣你就不會(huì )讀完了這篇文章才發(fā)現它對你沒(méi)有任何價(jià)值：
· 本文基于對Ant的了解。它是針對那些會(huì )用并喜歡Ant的讀者的。
· 這里所說(shuō)的編譯環(huán)境是指模組（modular）和模塊（module），而模塊又是由目錄和子目錄來(lái)定義的。（譯者注：模組modular是模塊module的集合。它由多個(gè)獨立的模塊構成。）這意味著(zhù)文件和源代碼被存放在許多不同的目錄中。因此，如果你使用類(lèi)似Eclipse或IntelliJ Idea這種可以幫你管理類(lèi)和文件的位置的IDE工具的話(huà)，本文對你會(huì )更加有益。當然，你也可以使用文本編譯器，但是恐怕你會(huì )發(fā)現你頻頻地在多棵“目錄樹(shù)”上爬上爬下。
概念首先，讓我們來(lái)談及掉隱藏在編譯環(huán)境之后的幾個(gè)核心概念。它們是模組，層級結構（hierarchical），和資源驅動(dòng)（artifact-driven）。它們確切的含義又是什么呢？
模組模組編譯是指圍繞軟件模塊來(lái)進(jìn)行組織的一種編譯方式。一個(gè)模塊是一個(gè)邏輯的，集合的，功能性單元，對應于系統中的一個(gè)特性。對于編譯環(huán)境而言，一個(gè)模塊表現為源代碼和配置文件的一個(gè)自我包含集合（self-contained collection），這些源代碼和配置文件用來(lái)構建表現了模塊所對應的那個(gè)命名特性的軟件。它幾乎和你修訂控制系統（RCS：Revision Control System）（例如CVS或者Subversion）中的目錄樹(shù)是一一對應的。舉幾個(gè)例子：security, administration, wiki, email都可以是一個(gè)模塊。
層級結構層級結構編譯是指含有分層模塊的編譯方式。也就是，對于一個(gè)模塊，它可能是由更小的，更特定的子模塊（submodule）來(lái)構成的。
如果一個(gè)模塊含有子模塊，那么它有責任保證那些子模塊以合適的方式被編譯。
隨后，我們會(huì )討論例子是如何應用層級結構的概念來(lái)建立編譯環(huán)境的。
物件驅動(dòng)物件驅動(dòng)編譯是指每個(gè)存在的模塊（module）或子模塊（submodule），都是為了產(chǎn)生一個(gè)單獨的，可部署的物件。在Java項目中，這些物件主要是.jar，.war，或.ear文件。在其他類(lèi)型的編譯中，它們通常是二進(jìn)制可執行文件或動(dòng)態(tài)連接庫（.dll或.so）。
編譯環(huán)境的例子也是物件驅動(dòng)的，我們將會(huì )討論它是如何創(chuàng )建可部署的物件的。
盡管這三個(gè)概念都很容易理解，但結合起來(lái)用在編譯環(huán)境中的話(huà)，它們會(huì )變得非常強大。
現在讓我們來(lái)看看編譯環(huán)境是如何組織的。
模組結構當有很多要去實(shí)現的時(shí)候，把問(wèn)題分解為若干個(gè)小的部分是個(gè)很有效的方法。我們需要一個(gè)好的分而治之（divide-and-conquer）的技術(shù)來(lái)幫助我們來(lái)管理大量的源碼。在編譯環(huán)境中創(chuàng )建編譯模塊是個(gè)好方法。
我們通過(guò)在應用程序的根目錄下創(chuàng )建一個(gè)目錄來(lái)創(chuàng )建一個(gè)模塊。這個(gè)新的目錄成為這個(gè)模塊的基礎。在每個(gè)模塊目錄下，我們存放與其相關(guān)的文件和源碼。
這是一個(gè)示例程序的編譯環(huán)境，按照模塊來(lái)組織：
appname/
|-- admin/
|-- core/
|-- db/
|-- lib/
|-- ordermgt/
|-- reports/
|-- web/
|-- build.xml 下面是每個(gè)節點(diǎn)的含義：
· 除了lib/ 以外的每個(gè)目錄都是一個(gè)模塊。在這個(gè)例子中，admin模塊提供了POJO的實(shí)現，它容許某人來(lái)管理應用（例如，創(chuàng )建用戶(hù)，授權等等）。同樣的，reports模塊中，有能夠產(chǎn)生報告的組件的實(shí)現。而core 模塊中是那些在很多或全部模塊中都用到的組件，它們不是真正地和系統的某個(gè)功能相聯(lián)系。（例如，StringUtil 類(lèi)）通常，其他地所有模塊都會(huì )依賴(lài)核心（core）模塊。
其他模塊與admin, reports, 及core模塊一樣：他們有著(zhù)各自的自包含的系統功能，并與其他模塊區別開(kāi)來(lái)。此外，由于我們的范例應用可以支持基于web的交互，我們還可以有一個(gè)web模塊，包含了用以創(chuàng )建一個(gè).war文件所需要的一切內容。
· lib/ 目錄比較特殊。它含有應用程序編譯或運行所需地所有第三方.jars文件。我們把其他模塊所需的所有第三方.jars文件放在這個(gè)目錄中，而不是它們自己的模塊中。原因如下：
1. 在一個(gè)地方更便于管理對第三方的依賴(lài)（third-party dependencies）?？梢栽谝粋€(gè)模塊的build.xml 文件中，利用Ant的<path> 語(yǔ)句來(lái)定義改模塊是否使用這些庫文件。
2. 通過(guò)排除重復.jars文件的可能性，從而避免了裝載類(lèi)或API的版本沖突。如果有不止一個(gè)模塊使用了一個(gè)負責存儲commons-logging.jar文件的Jakarta Commons Logging模塊，會(huì )發(fā)生什么情況？假設每個(gè)模塊都持有Jakarta Commons Logging模塊的備份，這樣就會(huì )有一個(gè)潛在的問(wèn)題――一個(gè)模塊所持有的備份和另外一個(gè)模塊所持有的版本不同。當應用程序開(kāi)始運行，只有第一個(gè)在classpath上找到的.jar文件被載入以滿(mǎn)足所需，這就潛在地引起了與其他模塊的沖突。我們通過(guò)在根目錄下只持有一個(gè).jar文件來(lái)避免這種沖突。
3. 對第三方的依賴(lài)隨你的源碼改變版本。瀏覽很多項目，會(huì )發(fā)現，這是你想把你所依賴(lài)的庫文件放在CVS上的最重要原因。通過(guò)這樣做，你能確保，無(wú)論你從CVS上導出的是那個(gè)版本或那個(gè)分支的軟件，你都能找到第三方類(lèi)庫的合適版本來(lái)支持你的軟件的特定版本。
· 根build.xml 文件是主要的管理文件。它知道為了編譯每個(gè)模塊，什么文件和目標（target：譯者注，應該是<target>，是Ant中的一個(gè)語(yǔ)句）是必須的。然后，由模塊來(lái)保證這些物件（artifact）被正確的編譯。
例如，假設一個(gè)項目正在編譯，現在是編譯ordermgt 模塊的時(shí)候了，根編譯文件（root build file）應該知道，去調用ordermgt/build.xml 文件中一個(gè)Ant任務(wù)來(lái)完成這編譯。而ordermgt/build.xml 文件應該確切的知道要編譯生成ordermgt .jar 文件需要些什么。而且，如果整個(gè)項目被編譯并合并入一個(gè).ear文件，這個(gè)根build.xml 文件應該知道如何去構建。
根build.xml 文件是怎么知道要去編譯一個(gè)模塊并且以何種順序來(lái)編譯的呢？下面是一個(gè)Ant XML文件的一部分，它顯示了build.xml文件是如何完成設定的目標的：
<!-- =========================================
Template target. Never called explicitly,
only used to pass calls to underlying
children modules.
========================================= -->
<target name="template" depends="init">
<-- Define the modules and the order in which
they are executed for any given target.
This means _order matters_. Any
dependencies that are to be satisfied by
one module for another must be declared
in the order the dependencies occur. -->
<echo>Executing "${target}" \
target for the core module...</echo>
<ant target="${target}" dir="core"/>
<echo>Executing "${target}" \
target for the admin module...</echo>
<ant target="${target}" dir="admin"/>
...
</target>
無(wú)論根build.xml 文件調用了哪個(gè)編譯目標，都由這個(gè)template 目標負責以一定的順序傳遞給相應的子模塊。例如，如果我們想要清理整個(gè)工程，我們應該只需在工程的根部調用clean 目標即可，然后下面的任務(wù)將被執行：
<!-- =========================================
Clean all modules.
========================================= -->
<target name="clean" depends="init">
<echo>Cleaning all builds"</echo>
<antcall target="template">
<param name="target" value="clean"/>
</antcall>
</target>
根build.xml 文件通過(guò)直接調用template 目標來(lái)間接地實(shí)現調用clean 目標，從而保證了所有模塊都被清理。
上面的模塊組織和相關(guān)的編譯目標真地使管理源碼和編譯變得更容易了。這種結構有助于你更快，更容易地找到你想要的源碼。而template 目標負責管理任務(wù)是如何執行的。
但模塊結構最精彩的部分是這里：
在完成了整個(gè)工程的完整編譯后，可以對任何模塊進(jìn)行獨立的編譯。只要在命令行中切換到該模塊目錄下，并執行：
> ant target然后那個(gè)模塊的build.xml 文件就會(huì )被執行。你可以在編譯的任何級別下運行任何目標，而且只對該級別進(jìn)行編譯。
為什么這點(diǎn)很重要？因為它容許你獨立地工作在你的模塊中，并且只對該模塊進(jìn)行編譯。這樣，每次你對該模塊源碼的修改都不需要你重新編譯整個(gè)工程，對于一個(gè)巨大的工程而言，這將節省很多時(shí)間。
現在，讓我們來(lái)看看一個(gè)獨立的模塊的內部是如何構造的。
模塊的內容我們按照一般的Java業(yè)界習慣來(lái)組織模塊的目錄結構，以便管理源碼。盡管有很多不同的習慣，我們的編譯環(huán)境中使用一下的目錄結構：
modulename
|-- build/
|-- etc/
|-- src/
|-- test/
|-- build.xml 下面是每個(gè)節點(diǎn)的含義：
· build: 這個(gè)目錄比較特殊，它是由模塊的編譯而產(chǎn)生的。除了它以外，上面所列出的其他文件和目錄都會(huì )被加入修訂控制系統（RCS：Revision Control System）。build目錄中包含編譯過(guò)程中所產(chǎn)生的所有文件，從自動(dòng)生成的XML文件到編譯完成的Java .class文件，以及最終的任何發(fā)布文件（distribution artifacts）（如.war, .jar, .ear,等等）。這使得清理編譯變得很容易，只要刪除這個(gè)目錄就好了。
· etc: 這個(gè)目錄中存放編譯或運行時(shí)（run time）模塊所需的配置文件。大多數時(shí)候，你會(huì )在這里找到屬性文件和XML配置文件，例如log4j.properties 或 struts-config.xml。假設有很多文件，他們通常被存放在他們相關(guān)組件的子目錄中。例如：etc/spring/, etc/struts/, etc/ejb/, 等等。
· src: 這是你源文件目錄樹(shù)的根目錄。這里除了與包和（或者）路徑相對應的目錄之外，就別無(wú)他物了。因此，在這里你經(jīng)常會(huì )看到com/ 或 net/ 或 org/ 目錄，作為com.whatever 或 net.something 或 org.mydomain 包的開(kāi)始。要注意，只有和classpath有一一對應關(guān)系的東西才能放在這個(gè)目錄中。例如：包目錄，或 .java源文件。
· test: 這個(gè)目錄用來(lái)存放你的測試類(lèi)文件。（例如，JUnit測試單元）。從目錄組織的角度出發(fā)，這里最重要的是，這里的包結構是src 目錄的嚴格鏡像。這很便于管理測試程序，因為你立即就會(huì )知道：moduleroot/test/com/domain/pkg/BusinessObjectTest
是對moduleroot/src/com/domain/pkg/BusinessObject的進(jìn)行的測試。這個(gè)簡(jiǎn)單的鏡像技術(shù)對于管理大量的code是非常有用的。它使你很容易的找到你的測試程序。
· build.xml: 這個(gè)Ant文件知道如何去做每件這個(gè)模塊需要做的事情，以完成編譯和分配它所負責的物件。如果當前模塊含有子模塊，那么它也知道如何去編譯以及按何種順序去編譯那些子模塊。子模塊和編譯順序都是我們很快要解釋的，非常重要的概念。
子模塊子模塊就是另外一個(gè)模塊（父模塊）的子集。你或許看過(guò)其他的模式――基于A(yíng)nt的扁平層級：例如，只有一層深度的結構。而我們的編譯結構要走的更遠一些：我們有2層。
繼續我們的編譯和子模塊的概念，你將會(huì )看到如下的一個(gè)編譯層次，模塊和子模塊目錄展開(kāi)如下：
module1/
submodule1.1/
|-- etc/
|-- src/
...
|-- build.xml
submodule1.2/
|-- etc/
|-- src/
...
|-- build.xml
build.xml
module2/
... OK, 這個(gè)看起來(lái)有點(diǎn)復雜。我們?yōu)槭裁葱枰@個(gè)？
讓我們補充點(diǎn)企業(yè)級應用和物件驅動(dòng)的背景知識，再來(lái)回答這個(gè)問(wèn)題。
企業(yè)級應用程序大部分情況下都是基于客戶(hù)/服務(wù)器模式的。即便你只是開(kāi)發(fā)一個(gè)網(wǎng)頁(yè)應用程序，它通常構成一個(gè)客戶(hù)/服務(wù)器MVC應用。這樣，網(wǎng)頁(yè)本身就是一個(gè)客戶(hù)視角，而“服務(wù)器”端組件通常是商業(yè)POJO，它代替發(fā)布網(wǎng)頁(yè)組件執行商業(yè)邏輯。盡管它們在一個(gè) .war文件中，但是在主要用于繪制視圖（rendering a view）（客戶(hù)端代碼）的代碼和用于處理商業(yè)請求（服務(wù)器端代碼）的代碼之間有明確的架構分離。至少，在這里是這樣的！
在傳統的客戶(hù)/服務(wù)器應用程序中，客戶(hù)和服務(wù)器的概念更加明顯。那里有獨立的客戶(hù)GUI通過(guò)socket和服務(wù)器端的商業(yè)對象進(jìn)行通信。
如果對于客戶(hù)應用程序我們只需要改動(dòng)客戶(hù)端代碼，對于服務(wù)器端程序只改動(dòng)服務(wù)器端源碼，那將是簡(jiǎn)潔而優(yōu)雅的。這兩層也共享一些通用代碼，因此向客戶(hù)端和服務(wù)器端發(fā)送共用的.jar文件也是好主意。我們的編譯環(huán)境有能力實(shí)現我們的想法。
接下來(lái)我們會(huì )看到子模塊是如何幫我我們實(shí)現物件驅動(dòng)編譯的。
分級結構和編譯物件部署場(chǎng)景（deployment scenario）只描述了物件驅動(dòng)編譯的表層需求：編譯環(huán)境中的每個(gè)模塊或子模塊復雜創(chuàng )建一個(gè)會(huì )被部署到客戶(hù)或服務(wù)器端的物件。在我們的編譯環(huán)境中這個(gè)很容易實(shí)現，只要把已有的模塊進(jìn)一步分解為common, client, 和 server 子模塊就好了。父子關(guān)系以及編譯責任委托也促成這種編譯層級結構。
以我們示例程序中的admin 模塊為例，讓我們看看在展開(kāi)的目錄樹(shù)中這種層級結構是怎樣的：
appname/
|-- admin/
|-- common/
|-- etc/
|-- src/
|-- test/
|-- build.xml
|-- client/
|-- etc/
|-- src/
|-- test/
|-- build.xml
|-- server/
|-- etc/
|-- src/
|-- test/
|-- build.xml
|-- build.xml
... 每個(gè)子模塊的內容都按照先前定義的構建，但是有些值得注意的不同：
admin 模塊沒(méi)有通常模塊的那些內容。它只含有子模塊和一個(gè)build.xml文件，而且它自己也不會(huì )產(chǎn)生任何編譯產(chǎn)物。而是通過(guò)先前描述的模板（template）技術(shù)來(lái)調用common/build.xml, server/build.xml, 和 client/build.xml 文件中的編譯目標來(lái)完成編譯工作的。
因此，如果你想編譯admin 模塊，你只需要切換到admin目錄下，然后運行Ant：
> cd admin/
> ant這個(gè)命令會(huì )調用admin的build.xml 文件，其結果是編譯common, server, 和 client 子模塊。在每個(gè)子模塊被編譯后，將會(huì )產(chǎn)生三個(gè)物件：
appname-admin-common.jar
appname-admin-server.jar
appname-admin-client.jar
common 和 server .jars 文件可以被部署到服務(wù)器端（例如，在一個(gè) .ear文件中），而common and client .jars 文件可以被部署到客戶(hù)端（如，在 .war文件的WEB-INF/lib 目錄中）。
每個(gè)子模塊的目的是什么呢？它們幫助以簡(jiǎn)潔的功能性子集來(lái)組織代碼，這些子集會(huì )被部署到應用程序的不同層面上。一下是上述三個(gè)子模塊通常所含有的內容：
· common: 模塊中，所有在客戶(hù)和服務(wù)器層都會(huì )用到的代碼。這通常意味這POJO接口，單元類(lèi)，等等。
· server:服務(wù)器層所需類(lèi)的實(shí)現。它們通常是商業(yè)POJO接口的實(shí)現，DAO為EIS連接的實(shí)現，等等。
· client: 客戶(hù)層所需類(lèi)的實(shí)現，例如Swing GUI對象，EJO遠程接口，等等。
這種子模塊的獨立性（granularity）及其相應的部署物件從4個(gè)方面對你產(chǎn)生實(shí)質(zhì)性幫助：
1. 下載時(shí)間：你可以確保獨立的客戶(hù)端應用程序，例如applet或Java Web Start 程序，只需下載程序運行所需的.jar文件的最小子集。這樣可以確保第一次運行的applet或應用程序能盡快的被下載。
2. 依賴(lài)性管理: 通過(guò)子模塊的build.xml 文件中Ant的<path> 標識，你可以添加當前子模塊所依賴(lài)的其他模塊或子模塊。這樣避免了任何懶惰或意外的使用了開(kāi)發(fā)者不支持的或在運行時(shí)不支持的API
。
3. 依賴(lài)性順序: 因為父模塊決定了子模塊的編譯順序，因此你可以重新設定以確保你寫(xiě)的客戶(hù)端代碼依賴(lài)于common 代碼，而不依賴(lài)于服務(wù)器端代碼。同樣，common 代碼不能依賴(lài)于服務(wù)器或客戶(hù)端代碼。如果你沒(méi)有這么做，編譯就會(huì )中止，你就會(huì )立即的得到警告，你用了你不該使用的類(lèi)。這聽(tīng)起來(lái)好像是很瑣碎的問(wèn)題，但是在復雜的工程或那些程序員有著(zhù)不同的經(jīng)驗的情況下，這個(gè)問(wèn)題會(huì )迅速浮出水面，而且不會(huì )在依賴(lài)性管理中被注意到。
4． 正如同處理模塊一樣，你也可以通過(guò)切換到子模塊的目錄里并運行以下命令來(lái)對一個(gè)子模塊進(jìn)行單獨編譯：
> ant 而Ant會(huì )只編譯該模塊，節省了時(shí)間。
結論模塊和子模塊看起來(lái)有點(diǎn)復雜。在這點(diǎn)上它們在你看來(lái)好象沒(méi)此必要。但請相信我的經(jīng)驗，它們極大的簡(jiǎn)化你如何管理源碼和關(guān)聯(lián)文件，以及Ant是如何編譯你的產(chǎn)品的。在這里定義的結構真真正正地使得產(chǎn)品特性和源碼管理在團隊環(huán)境下變得更容易了。它剔除了為了實(shí)現全部組織工作所臆想的許多任務(wù)，而且一旦建立起來(lái)，它是相當透明的。如果你正在開(kāi)始一項新的客戶(hù)/服務(wù)器模式的項目，那么就試著(zhù)應用它。你會(huì )有更多的時(shí)間投入到你的程序中，而不用在為配置管理而但心。
特別感謝Transdyn delivers 的Jeremy Haile，他提供了有意義的信息和審閱了本文。
資源· 本文的范例代碼:[
下載文件]
·
Ant ·
JUnit(參見(jiàn)O‘Reilly CodeZoo: JUnit)
Les A. Hazlewood 是Atlanta, Georgia.的 Roundbox Media 的軟件工程負責人。
