罐子包裝和配送

我們有一些共同代碼在預期的包裝。一些包是 handler, processor, util, registration等罐子包裝和配送

常見在這裏表示，這些將是跨多個Java/Java EE的再利用項目它們是彼此無關。

問題是在包裝分銷。

每個軟件包包含不同的功能單元，但放在一起，它們是一個API。

我們是否應該將單個功能捆綁到一個JAR中，並最終生成8到10個罐子。例如：處理器罐子，罐子登記等

或

我們應該採取的最小公分母的做法，是5個強制包在基本構建成一個單一的罐子。任何人都需要該罐子作爲基礎，並可以選擇附加罐。

我們的構建系統是Ant + Ivy，這些依賴關係將在編譯和構建時解決。

來源

2011-07-22 shinynewbike

除非你有很多很多的API類（想想Spring）或者意識到它們之間存在一些干擾，否則我認爲沒有什麼理由將它們分解成單獨的jar。在獨立的罐子中打破API的唯一原因是讓不同的團隊獨立工作。

管理單個jar簡化了很多事情，它不值得修復不存在的問題。

來源

2011-07-22 05:21:04

謝謝 - 這是有道理的。我們在這個公司有一個爭論 - 共同干涉是有效的 – shinynewbike

它總是一個激烈爭論的主題。我的觀點通常是 - 越簡單越好。 –

獨立罐子的解決方案更好。順便說一句，如果你使用maven，每個邏輯組件都有自己的pom.xml，這是唯一的選擇。

一個大罐子具有更容易分配的優點。例如，如果您的用戶從互聯網上下載jar並手動安裝它，那麼處理一個jar比處理很多jar更容易。但如果不是這種情況，我建議你使用多jar解決方案。但不要忘記每個罐子的版本。至少把版本放到manifest.mf文件中。 Maven也將版本作爲jar名稱的一部分。這是非常好的做法。

來源

2011-07-22 05:24:44 AlexR

如果API非常龐大更好的分成多張罐子否則創建多個罐子

單罐子的好處 如果任何應用程序要使用一個以上的罐子如登記以及UTIL。他/她必須只包括一個罐子。

限制如果你的jar的大小非常大，你只能在jar中使用util類。如果應用程序的大小對您來說不是問題，則可能會增加應用程序的大小，那麼您可以避免它。

來源

2011-07-22 05:28:35

罐子包裝和配送

回答

相關問題