企業應用級別的Ant模組編譯環境

領測軟件測試網

　　 
　　編譯環境對于今日的Java企業級應用程序來說，越來越難于管理了。堆積如山的代碼，配置文件，以及對第三方的依賴（third-party dependencies）都使得管理編譯環境變得困難。
　　

　　簡而言之，我們勉強接受那種把所有的源代碼放在一個根目錄下，所有的配置文件放在另一個根目錄下，而第三方類庫也這樣處理的做法。但是企業級編譯環境很少這么做。今日的企業級Java項目，在結構，功能，以及組織上都很復雜。它們通常都有大量的源代碼和支持資源（屬性文件，圖片，等等。編者注：原文為supporting artifacts，直譯為支持物件，但這里根據上下文意譯為支持資源較妥）要去管理。有這么多的東西去管理，當一個開發團隊試圖去建立一個優化的編譯方案時，他們常常感到困惑和挫敗。
　　
　　如果，不管這個項目有多大，我們的編譯環境都能夠在統一的構架中簡潔地處理我們所有的源代碼，事情是不是會變得好一些呢？本文將展示一個Ant編譯環境的例子，它來自我對多年來的多個項目的經驗的修改。此時此地，它或許不是最好的方案，但是它的確經歷了時間的考驗，也一定會幫助你建立并運行在大多數項目上，不管是大是小。
　　
　　警告
　　
　　先就一些問題說明一下，這樣你就不會讀完了這篇文章才發現它對你沒有任何價值：
　　
　　· 本文基于對Ant的了解。它是針對那些會用并喜歡Ant的讀者的。
　　
　　· 這里所說的編譯環境是指模組（modular）和模塊（module），而模塊又是由目錄和子目錄來定義的。（譯者注：模組modular是模塊module的集合。它由多個獨立的模塊構成。）這意味著文件和源代碼被存放在許多不同的目錄中。因此，如果你使用類似Eclipse或IntelliJ Idea這種可以幫你管理類和文件的位置的IDE工具的話，本文對你會更加有益。當然，你也可以使用文本編譯器，但是恐怕你會發現你頻頻地在多棵“目錄樹”上爬上爬下。
　　
　　概念
　　
　　首先，讓我們來談及掉隱藏在編譯環境之后的幾個核心概念。它們是模組，層級結構（hierarchical），和資源驅動（artifact-driven）。它們確切的含義又是什么呢？
　　
　　模組
　　
　　模組編譯是指圍繞軟件模塊來進行組織的一種編譯方式。一個模塊是一個邏輯的，集合的，功能性單元，對應于系統中的一個特性。對于編譯環境而言，一個模塊表現為源代碼和配置文件的一個自我包含集合（self-contained collection），這些源代碼和配置文件用來構建表現了模塊所對應的那個命名特性的軟件。它幾乎和你修訂控制系統（RCS：Revision Control System）（例如CVS或者Subversion）中的目錄樹是一一對應的。舉幾個例子：security, administration, wiki, email都可以是一個模塊。
　　
　　層級結構
　　
　　層級結構編譯是指含有分層模塊的編譯方式。也就是，對于一個模塊，它可能是由更小的，更特定的子模塊（submodule）來構成的。
　　
　　如果一個模塊含有子模塊，那么它有責任保證那些子模塊以合適的方式被編譯。
　　
　　隨后，我們會討論例子是如何應用層級結構的概念來建立編譯環境的。
　　
　　物件驅動
　　
　　物件驅動編譯是指每個存在的模塊（module）或子模塊（submodule），都是為了產生一個單獨的，可部署的物件。在Java項目中，這些物件主要是.jar，.war，或.ear文件。在其他類型的編譯中，它們通常是二進制可執行文件或動態連接庫（.dll或.so）。
　　
　　編譯環境的例子也是物件驅動的，我們將會討論它是如何創建可部署的物件的。
　　
　　盡管這三個概念都很容易理解，但結合起來用在編譯環境中的話，它們會變得非常強大。
　　
　　現在讓我們來看看編譯環境是如何組織的。
　　
　　模組結構
　　
　　當有很多要去實現的時候，把問題分解為若干個小的部分是個很有效的方法。我們需要一個好的分而治之（divide-and-conquer）的技術來幫助我們來管理大量的源碼。在編譯環境中創建編譯模塊是個好方法。
　　
　　我們通過在應用程序的根目錄下創建一個目錄來創建一個模塊。這個新的目錄成為這個模塊的基礎。在每個模塊目錄下，我們存放與其相關的文件和源碼。
　　
　　這是一個示例程序的編譯環境，按照模塊來組織：
　　
　　appname/
　　|-- admin/
　　|-- core/
　　|-- db/
　　|-- lib/
　　|-- ordermgt/
　　|-- reports/
　　|-- web/
　　|-- build.xml
　　
　　下面是每個節點的含義：
　　
　　· 除了lib/ 以外的每個目錄都是一個模塊。在這個例子中，admin模塊提供了POJO的實現，它容許某人來管理應用（例如，創建用戶，授權等等）。同樣的，reports模塊中，有能夠產生報告的組件的實現。而core 模塊中是那些在很多或全部模塊中都用到的組件，它們不是真正地和系統的某個功能相聯系。（例如，StringUtil 類）通常，其他地所有模塊都會依賴核心（core）模塊。
　　
　　其他模塊與admin, reports, 及core模塊一樣：他們有著各自的自包含的系統功能，并與其他模塊區別開來。此外，由于我們的范例應用可以支持基于web的交互，我們還可以有一個web模塊，包含了用以創建一個.war文件所需要的一切內容。
　　
　　· lib/ 目錄比較特殊。它含有應用程序編譯或運行所需地所有第三方.jars文件。我們把其他模塊所需的所有第三方.jars文件放在這個目錄中，而不是它們自己的模塊中。原因如下：
　　
　　1. 在一個地方更便于管理對第三方的依賴（third-party dependencies）�？梢栽谝粋�模塊的build.xml 文件中，利用Ant的<path> 語句來定義改模塊是否使用這些庫文件。
　　
　　2. 通過排除重復.jars文件的可能性，從而避免了裝載類或API的版本沖突。如果有不止一個模塊使用了一個負責存儲commons-logging.jar文件的Jakarta Commons Logging模塊，會發生什么情況？假設每個模塊都持有Jakarta Commons Logging模塊的備份，這樣就會有一個潛在的問題――一個模塊所持有的備份和另外一個模塊所持有的版本不同。當應用程序開始運行，只有第一個在classpath上找到的.jar文件被載入以滿足所需，這就潛在地引起了與其他模塊的沖突。我們通過在根目錄下只持有一個.jar文件來避免這種沖突。
　　
　　3. 對第三方的依賴隨你的源碼改變版本。瀏覽很多項目，會發現，這是你想把你所依賴的庫文件放在CVS上的最重要原因。通過這樣做，你能確保，無論你從CVS上導出的是那個版本或那個分支的軟件，你都能找到第三方類庫的合適版本來支持你的軟件的特定版本。
　　
　　· 根build.xml 文件是主要的管理文件。它知道為了編譯每個模塊，什么文件和目標（target：譯者注，應該是<target>，是Ant中的一個語句）是必須的。然后，由模塊來保證這些物件（artifact）被正確的編譯。
　　
　　例如，假設一個項目正在編譯，現在是編譯ordermgt 模塊的時候了，根編譯文件（root build file）應該知道，去調用ordermgt/build.xml 文件中一個Ant任務來完成這編譯。而ordermgt/build.xml 文件應該確切的知道要編譯生成ordermgt .jar 文件需要些什么。而且，如果整個項目被編譯并合并入一個.ear文件，這個根build.xml 文件應該知道如何去構建。
　　
　　根build.xml 文件是怎么知道要去編譯一個模塊并且以何種順序來編譯的呢？下面是一個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>
　　
　　無論根build.xml 文件調用了哪個編譯目標，都由這個template 目標負責以一定的順序傳遞給相應的子模塊。例如，如果我們想要清理整個工程，我們應該只需在工程的根部調用clean 目標即可，然后下面的任務將被執行：
　　
　　<!-- =========================================　　 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 文件通過直接調用template 目標來間接地實現調用clean 目標，從而保證了所有模塊都被清理。
　　
　　上面的模塊組織和相關的編譯目標真地使管理源碼和編譯變得更容易了。這種結構有助于你更快，更容易地找到你想要的源碼。而template 目標負責管理任務是如何執行的。
　　
　　但模塊結構最精彩的部分是這里：
　　
　　在完成了整個工程的完整編譯后，可以對任何模塊進行獨立的編譯。只要在命令行中切換到該模塊目錄下，并執行：
　　
　　> ant target

文章來源于領測軟件測試網 http://www.kjueaiud.com/