簡體 English 中英

基於Ant的構建的Java項目布局最佳實踐

[英]Java Project Layout Best Practices for Ant-based Builds

原文 2010-11-23 15:44:45 1 4 java/ ant/ build-process/ directory-structure

我有點震驚（如果？）這個確切的問題沒有被問到，但15分鍾的掃描SO並沒有完全匹配。 （如果我錯了，請指出正確的方法並投票結束...）

問題1：

在Ant構建系統下布置Java項目的最佳實踐是什么？ 出於我們的目的，我們有以下背景（可能大多數是無關緊要的）：

大多數開發人員都在使用Eclipse（並非所有）
項目維持顛覆
項目構建最近已遷移到Hudson，我們希望使用發布插件來管理版本，以及一些自定義腳本來處理自動部署
這個項目是一個“常規”應用程序，一種“生產原型”，用戶數量非常有限，但它們位於具有氣隙分離的遠程站點，因此可以提供版本化，可追溯的工件，以便於安裝，手動數據收集/恢復，和遠程診斷很重要。
一些依賴項（JAR）包含在SVN repo中; 如果需要，可以在構建時通過ant腳本獲取其他內容。 沒有像Ivy那樣花哨的東西（請不要告訴我切換到Maven3 ......我知道，如果/適當的時候到了，我們會這樣做。）
Build包括JUnit，FindBugs，CheckStyle，PMD，JavaDoc，一些自定義文檔生成
兩個或三個主JAR工件（一個主應用程序工件加上幾個最小的API JAR，包含在幾個耦合的應用程序中）
希望分發以下分發工件：
- 一個“完整”源+ bin tarball，所有依賴項已解析，jars和JavaDoc預構建
- 一個bin tarball，只有docs和JavaDoc，jar和輔助包裝腳本等
- 一個“合作伙伴”源+ bin，它具有合作伙伴開發人員可能關注的“共享”源以及相關的測試用例

目前的結構看起來像這樣

project-root/
project-root/source                 
project-root/source/java             // main application (depends on -icd)
project-root/source/java-icd         // distributable interface code
project-root/source/test             // JUnit test sources
project-root/etc                     // config/data stuff
project-root/doc                     // pre-formatted docs (release notes, howtos, etc)
project-root/lib                     // where SVN-managed or Ant-retrieved Jars go
project-root/bin                     // scripts, etc...

在構建時，它擴展到包括：

build/classes                        // Compiled classes
build/classes-icd 
build/classes-test
build/javadoc
build/javadoc-icd                    
build/lib                            // Compiled JAR artifacts
build/reports                        // PMD, FindBugs, JUnit, etc... output goes here
build/dist                           // tarballs, zipfiles, doc.jar/src.jar type things, etc..
build/java                           // Autogenerated .java products
build/build.properties               // build and release numbering, etc...

問題2：

我怎樣才能保持版本控制項目和建設時工件之間在開發樹嚴格分離，同時產生一個連貫的分布如上，讓我來開發和測試過程中對待開發樹作為業務/分配？ 特別是，我不喜歡在頂級lib目錄中使用我的<jar>任務drop .jar文件 - 開發人員樹中的該目錄是不可侵犯的SVN區域。 但是使用build/lib/*.jar分發一些供公眾使用的東西是令人困惑的煩惱。 我們希望在分發中的一致位置出現的文檔和其他構建工件也是如此，但不希望開發人員和用戶使用完全不同的目錄結構。

將所有生成的產品放在一個單獨的build/目錄中對於開發時非常好，但它是一個令人煩惱的工件。 出於分發的目的，我寧願將所有JAR放在一個lib位置，事實上，像下面這樣的結構最有意義。 目前，我們建立在與飛這種結構ant dist做一些復雜的路徑的操作以.tar.gz和.zip文物都建。

我認為dist應該是這樣的：

project-root/
project-root/source                  // present in only some dists 
project-root/etc                     // same as in development tree
project-root/doc                     // same as in development tree
project-root/doc/javadoc             // from build 
project-root/lib                     // all dependency and built JAR files
project-root/bin                     // same as in development tree
build.properties               // build and release numbering, etc...

這個問題只是關於“我如何保持清潔的開發和分配項目布局？” 正如我上面所說; 同時也收集有關Java / Ant項目布局的信息，以及對我們特定方法的批評。 （是的，如果您認為它應該是社區Wiki，我會這樣做......）

4 個解決方案

在布局方面，我們使用的東西已經發展成非常接近Maven布局的東西（見這里）。 這是一個非常實用的布局，已被很多人使用。 並且，如果您想稍后切換到Maven，那么您已經完成了設置。 我們有幾個變體，其中最重要的是我們將自動化單元和集成測試分開。

在混合來源和建造人工制品方面 - 我當然會建議反對它。 正如您所見，它與IDE索引和版本控制相混淆，並且通常會使生活變得困難。

據我所知，要么必須接受這種混合，要么將依賴項作為構建的一部分進行復制，並將輸出視為一個單獨的項目 - 如果需要，可能會在另一個IDE窗口中不斷打開。 無論如何，將“作為用戶”的工作與作為發布包的“生產者”混合的想法聽起來會讓人感到困惑。

我的一個建議是你分發的目錄樹不應該是CVS中的目錄樹。 有一個腳本將build目錄放在一起構建，然后將其拉上。 該腳本可以將源控制文件和派生文件組合到其內容中。 它還可以執行諸如清除SVN目錄之類的操作，您不想分發這些目錄。 如果您希望能夠以相同的方式處理開發和分布式樹，只需確保dist的布局與開發項目的布局相同 - 最簡單的方法是復制除build子目錄之外的所有內容。（和CVS目錄，也許像Eclipse .project和.classpath這樣的東西）。

我懷疑你不會喜歡這個建議。 您可能認為分布式文件只是開發環境的可移植版本 - 但我認為它不是，它永遠不會是，並且它不需要。 如果你能接受這個想法，你可能會覺得我的建議很合適。

編輯：我想了一下，看了一下我使用的一些腳本。 我認為在這種情況下我要做的就是在開發過程中建立一個單獨的樹; 將執行環境指向project-root / build / app（或者如果可以的話，可能是project-root / build）而不是project-root，然后是符號鏈接（或者如果沒有符號鏈接則復制）所有必需品（無論是靜態的），從項目根目錄，或從構建中派生出來的那個。 然后，構建分布可能就像壓縮該樹一樣簡單（當然，使用解析符號鏈接的工具）。 關於這一點的好處是它允許執行樹的結構非常干凈 - 它不包含源目錄，IDE文件，構建腳本或項目內部的其他支持文件等。如果您正在使用Subversion ，它仍然包含靜態區域符號鏈接的任何內容中的.svn目錄; 如果您使用的是Mercurial，它將不包含任何.hg內容。