內部工件是否屬於一個存儲庫？

Question

我們的團隊正在圍繞圖書館知識庫的問題努力工作。我使用過Maven，並且我熟悉常春藤。我們毫不懷疑，對於第三方罐，集成到構建系統中的公共存儲庫具有巨大的優勢。

圍繞着如何處理嚴格內部的工件而奮鬥。我們有很多使用Maven等一些不同構建工具的工件，但實質上它們都是一個產品的一部分（一個團隊負責所有這些工具）。不幸的是，我們目前沒有爲每個項目生產一件神器，但我們正朝着這個方向前進。開發人員會檢查所有項目。

我們看到兩個選項：

1）把所有的文物，甚至內部的人與任何第三方jar。每個jar都被構建併發布到存儲庫，其他工件項目將引用所有項目的存儲庫。

2）每個項目直接引用其他「兄弟」項目。有一個「主項目」通過適當的依賴性順序觸發所有其他項目的構建。在IDE（eclipse）中，每個項目直接引用它的依賴項目（源代碼）。構建工具查看引用.jar的兄弟項目。

很明顯，開源世界正朝着存儲庫模型發展。但在我們看來，他們的需求可能不同。大多數此類項目都非常獨立，我們強烈懷疑用戶很少在項目間進行更改。現在客戶更容易跟蹤和了解頻繁的升級。

但是，它增加了一個負擔，因爲您必須單獨發佈更改。在我們的例子中，我們只是想承諾源代碼控制（我們每天做20到50次）。

我知道，Maven的可能解決所有這些問題，但球隊不將一切轉換成Maven的。除了maven，你有什麼建議（以及爲什麼）？

Answer 1

如果一個項目產生多個jar文件（很多都是這樣），我會仔細考慮每個jar是否會被其他項目重用。

如果是，該jar應作爲庫進入存儲庫，因爲它通過允許您將其指定爲依賴項來促進重用。

如果不是，這將是一個所謂的「多項目」，其中整個項目是由這些部分構成的。單個罐子可能不需要單獨存儲在回購中。只是最終完成的神器。

Gradle絕對是您的選擇：它可以使用Ant任務並調用Ant腳本，理解Maven pom文件並很好地處理多項目。 Maven也可以做很多事情，如果你有足夠的耐心，Ant + Ivy可以。

Answer 2

沒有必要只選擇其中一個選項。我成功地將兩者結合使用。如果一個項目由多個模塊組成，它們全部構建在一起，並且然後被傳遞到存儲庫。但是，上傳僅適用於「官方」或「發佈」版本。正在進行的開發構建是在開發人員的機器上完成的。你不必爲此使用Maven。常春藤會工作，甚至手動過程。 「工件存儲庫」可能是優秀的products可用或只是文件系統掛載點之一。

這一切都是要找出適當的組件邊界。

當您說「開發人員會檢查所有項目」時，沒關係。你永遠不知道什麼時候你可能想要改變;準備工作拷貝沒有任何壞處。但是，你是否真的想讓每個開發人員在本地構建每個工件，即使他們不需要改變它？真的，每個開發者都在改變每一件神器嗎？

或者，也許你只是沒有一個非常大的產品或一個非常大的團隊。在有許多子項目（本身可能有子模塊）的單個項目中開發沒有任何問題。每個人都在一起工作。從頂部一個單一的「全部構建」完成這項工作。簡單，工作，快（足夠）。那麼在這種情況下你會使用共享庫嗎？可能沒什麼。

也許你需要等到你的項目/團隊變得更大，然後才能看到從分裂中獲益。但我向你保證：你有一些基本的組件，這些組件依賴於許多項目（直接或間接），但它們本身並不依賴任何內部工件。理想情況下，這些組件在典型的開發週期中變化不大。我對你的建議是雙重的：

1. 建立一個內部存儲庫，因爲你已經同意你會從中受益，如果只爲第三方jar。
2. 考慮的最根本的項目分成單獨的生成，並提供其神器（S）到倉庫，然後有系統的其餘部分引用它彷彿它是一個第三方的神器。

如果像這樣的分割工作，您會發現只在需要時才重建該基本部分，而項目其餘部分（對於開發人員）的構建週期會更快一個相應的數量：雙贏。此外，您可以針對基本組件使用不同的交付時間表（如果需要），使其更加慎重和可控（這與應用於此類組件的情況相同）。這有助於促進增長。