在Subversion / Maven / Hudson中管理大型多模塊項目

Question

我們有一個相當大的Java應用程序，其中包含大量的Maven工件。 每個子系統在子版本樹中都有自己的文件夾，其中包含trunk /，branchs和tag /子文件夾，並承載多個工件。 Maven POM的層次結構具有多個級別。 甚至依賴項管理也分為不同的模塊。 該應用程序被部署為多個WAR和其他Zip / JAR內容。

在構建和部署它的過程中，我經常不得不將應用程序視為一個單元。 我遇到了很多困難，想在這里分享。

1. Subversion布局 ：首先我不能只用一個命令檢出整個代碼庫。 它太大了，當我從頂層開始並檢出所有子項目的所有分支時，將花費很長時間。 我猜目前減少工件的數量並不是真正的選擇，因為這會導致太多的根本變化。 但是，使用聚合分支文件夾的另一種Subversion布局確實會有所幫助。 我嘗試的一種解決方法是制作一個單獨的文件夾，其中包含許多Subversion外部組件，這些文件夾將正確的子文件夾聚集在一起。 然后，例如，我可以使用頂級多模塊工件中的一個maven命令來構建整個內容。

2. 發布 ：在整個代碼庫中完成了發布。 首先，我制作了一個巨大的依賴圖，在其中使用了專門為該項目編寫的自定義工具，因為不可能直接使用Maven做到這一點。 然后，我必須在依賴關系樹中逐步釋放一層工件，從底部開始沒有任何進一步依賴的工件，如果成功將父POM適應新版本，則構建它們，然后移至下一層。 有時候，我覺得所有版本控制工作都要進行兩次，一次是在Subversion中，一次是在所有POM中。 發行插件似乎還不能自動適應依賴性管理。

3. 哈德遜（Hudson） ：在哈德遜，我們為所有父物品提供了20個工作。 對於每個工件，有3個活動分支。 這使60個工作。 每次分支更改都會導致瀏覽器中的大量鼠標單擊工作。 至少依賴作業的自動構建觸發正在運行。 但是，如果將模塊拆分為編譯作業和報告作業，則會再次引起問題。 通常，編譯要比生成報告更為頻繁，並且后者不應減慢前者的工作速度。 但是，每當報表作業運行時，它也會觸發所有編譯作業。 如果確實部署了工件，Hudson似乎無法僅觸發依賴的作業。 我還嘗試為整個項目進行一個巨大的多模塊構建，但是增量構建功能無法正常工作。 沒有它，構建將花費太長時間。 但是需要構建依賴的工件，因為您永遠無法確定一個工件會導致什么變化。

4. 匯總報告 ：我尚未弄清楚如何為父POM的每個級別生成單元測試，測試覆蓋率，檢查樣式​​和其他報告的匯總報告。 有些插件甚至不支持聚合選項。 對於其他人，我必須為層次結構中的每個級別再次進行構建。 Maven站點報告還可以，但是它們似乎是靜態的，並且在瀏覽它們時用途有限。 也許這里更好的選擇是使用諸如Sonar Source之類的工具或其他一些源代碼分析工具。 同樣，將這些報告整合到Hudson中對我來說也不理想。

從我的角度來看，我只想擁有一個大型存儲庫，可以在其中簽出一個目錄，從源代碼構建所有內容，為發行版制作一個標簽/版本，不依賴任何外部存儲庫，並在Hudson中配置一項作業。 但這可能與不同開發人員團隊的需求相去甚遠。 似乎很難找到一種可管理的方式。

Answer 1

我不知道這是否是一個簡單的答案，但是我有一個類似的項目（按代碼進行）：2個大型應用程序，一個具有大約10個模塊，一個具有15個模塊。 我們將所有內容都存儲在一個Subversion存儲庫中（例如svn / trunk / app1和svn / trunk / app02）。 在根文件夾（svn / trunk）中，我們有一個非常簡單的pom，它將版本和兩個應用程序都定義為子模塊。

通過此設置，我們可以完成您提到的大多數事情。 甚至與每個開發團隊分開，因為每個團隊都致力於不同的文件夾/項目。 我們甚至存儲其他工件，例如文檔和設計（svn / trunk / documentation），因此我們可以跟蹤特定版本的文檔。

我知道這不能解決您的第一個問題（您無法檢出所有代碼庫），但是為什么需要“檢出所有子項目的所有分支”？ 聽起來不對。 您是否與svn服務器建立了快速連接？

注意：我們不會生成合並報告，因為我們對每個應用程序都有一個報告比較感興趣，因為它們有很大的不同。