Java的jar文件到存儲庫（CVS，SVN ..）

Question

爲什麼這是一個壞主意提交Java的jar文件到存儲庫（CVS，SVN ..）

Answer 1

因爲你可以從源頭上重建它們。如果您正在討論項目所需的第三方JAR文件，那麼最好將它們提交到存儲庫中，以便該項目是獨立的。

Answer 2

它們是二進制文件：

• 最好是引用來源，因爲這是你使用的是什麼源控制了。
• 系統無法告訴您文件之間的差異
• 如果它們是從同一個存儲庫中的源代碼編譯的，它們將成爲合併衝突的來源。
• 某些系統（如SVN）對大型二進制文件處理不好。

換句話說，更好地引用源代碼，並調整您的構建腳本以使一切正常。

Answer 3

將jar文件提交給SCM的決定通常受使用的構建工具的影響。如果以傳統方式使用Maven，那麼你並沒有真正的選擇。但是如果您的構建系統允許您選擇，我認爲將您的依賴關係提交給SCM以及取決於它們的源代碼是一個好主意。

這適用於與您的項目分開發布週期的第三方罐子和內部罐子。例如，如果你有一個包含公共實用類的內部jar文件，我會在每個使用它的項目下將它提交給SCM。

如果使用CVS，請注意它不能有效地處理二進制文件。 SVN存儲庫不會區分二進制文件和文本文件。

http://svnbook.red-bean.com/en/1.5/svn.forcvs.binary-and-trans.html

更新響應張貼由Mark答案：

WRT圓點1：我會說這是不是很常見的，甚至大型項目有數百依賴。無論如何，磁盤使用率（通過在每個使用它的項目中保留一個依賴項的副本）不應該成爲您的主要關注點。與處理Maven存儲庫複雜性所花費的時間相比，磁盤空間便宜。無論如何，本地Maven倉庫將消耗比實際使用的依賴關係更多的磁盤空間。

項目符號3：Maven不會節省您等待網絡流量的時間。事實恰恰相反。通過源代碼管理中的依賴關係，您可以執行結帳，然後從一個分支切換到另一個分支。你很少需要再次結賬相同的罐子。如果你這樣做，它只需要幾分鐘。 Maven是一個緩慢構建工具的主要原因是即使在沒有需要的情況下，它也可以執行所有的網絡訪問。

Bullet Point 4：你的觀點不是反對在SCM中存儲jar的爭論，Maven只有在你學會了它之後纔會很容易，它只是在出現問題時纔有效。然後變得困難，你的效率收益可能會很快消失。就效率而言，Maven在事情正常時有一個小的好處，當它沒有時會有很大的缺點。

Bullet Point 5：像SVN這樣的版本控制系統不會爲每個文件的每個版本保留一個單獨的副本。它將它們有效地存儲爲增量。您的SVN存儲庫很可能會增長到「難以管理」的大小。

子彈點6：你這裏的點不是反對存儲文件的論點是SCM。您提到的用例可以通過自定義Ant構建輕鬆處理。

Answer 4

源代碼管理系統設計用於保存文本源代碼。他們可以保存二進制文件，但這不是他們設計的。在某些情況下，將二進制文件放在源代碼管理中是有道理的，但通常以不同的方式更好地管理Java依賴項。

理想的設置是讓您在源代碼管理之外管理您的依賴項。你應該能夠在源代碼之外管理你的依賴關係，並簡單地從源代碼中「指向」所需的依賴關係。這有幾個優點：

• 你可以有一些依賴於相同的二進制項目不保持每個二進制的單獨副本。一箇中等規模的項目有數百個依賴的二進制文件是很常見的。這會導致大量的重複，浪費本地和備份資源。
• 版本的二進制文件可以在您的本地環境或企業實體內集中管理。
• 在許多情況下，源控制服務器不是本地資源。添加一堆二進制文件會減慢速度，因爲它會增加需要通過較慢連接發送的數據量。
• 如果您正在創建一場戰爭，可能會有一些需要進行開發的jar，但不包括部署，反之亦然。良好的依賴管理工具可以讓您輕鬆高效地處理這些類型的問題。
• 如果您依賴於來自另一個項目的二進制文件，它可能會頻繁更改。這意味着你可以不斷用新版本覆蓋二進制文件。由於版本控制將保留每個副本，因此它可能會迅速增長到無法管理的大小 - 尤其是如果您有任何類型的持續集成或自動構建腳本來創建這些二進制文件。
• 依賴關係管理系統爲您如何依賴二進制文件提供了一定程度的靈活性。例如，在本地計算機上，當它位於文件系統上時，可能需要依賴最新版本的依賴項。但是，當您部署應用程序時，需要將依賴項打包爲jar幷包含在文件中。

Maven的依賴關係管理功能爲您解決了這些問題，並可幫助您根據需要查找和檢索二進制依賴項。常春藤是另一個工具，也是這樣做的，但對於Ant來說。

Answer 5

所以，你有一個使用一些外部依賴的項目。這種依賴性是衆所周知的。他們都有

• A組（通常，組織/銳意創建它們）
• 的標識符（自己的名字）
• 一個版本

在Maven的術語，這些信息被稱爲神器（你的Jar）座標。我所討論的依賴關係是內部的（對於Web應用程序，它可以是你的服務/域層）或外部的（log4j，jdbc驅動程序，Java EE框架，你的名字，...）。所有這些依賴關係（也稱爲構件）實際上都處於其最低級別，即CVS/SVN/GIT無法有效存儲的二進制文件（JAR/WAR/EAR）。事實上，SCM使用版本化內容的假設，即差異化操作效率最高的內容）僅爲文本。因此，當存儲二進制數據時，它們很少存儲優化（與僅存儲版本差異的文本相反）。

因此，我傾向於建議您使用依賴管理構建系統，如maven,Ivy或Gradle。使用這樣一個工具，你將會在你的SCM文件（或者XML文件）中聲明你的所有依賴關係（事實上，在這個文件中，你將聲明你的依賴關係的工件座標）。但你的依賴關係不在SCM中。相反，每個開發人員都將在開發機器上下載它們。

這會將一些網絡負載從SCM服務器轉移到互聯網（該帶寬通常比內部企業網絡更受限制），並詢問工件的長期可用性問題。這兩個答案都得到了解決（至少在很多工作中，但我相信常春藤和Gradle能夠連接到這樣的工具 - 而且似乎有人在這個問題上提出了一些問題）使用企業代理，如Nexus,Artifactory和其他。

這些工具的美妙之處在於，它們在內部網絡中提供了所有必需工件的視圖，儘可能讓您在這些存儲庫中部署自己的工件，從而使您的代碼的共享變得輕鬆而獨立來源（這可能是一個優勢）。

總結這個長答覆：使用Ivy/Maven/Gradle而不是簡單的Ant構建。這些工具將允許您定義您的依賴關係，並完成下載這些依賴項的所有工作，並確保您使用聲明的版本。在我個人的筆記中，我發現這些工具的那一天，我對Java中依賴關係處理的想法是從噩夢到天堂，因爲我現在只需要說我使用這個工具的非常版本，而maven（在我的情況），做所有下載它並存儲在我的計算機上的正確位置的後臺工作。