2012-03-01 33 views
6

假設您有一組使用各種版本的公用庫(如Spring)的Web應用程序。我有一個業務邏輯庫也使用這個公共庫。到目前爲止沒有問題,但一路上公共庫的一個版本改變了抽象類的定義並打破了業務邏輯庫。在Maven中檢測不兼容的依賴關係?

所以我結束了一個兼容版本表看起來像這樣...

business-lib-version | common-lib-version 
     1.0   |  1.0 
     1.1   |  2.0 

我不想業務庫版本在使用應用程序驅動公共庫版本。相反,我想根據公共庫選擇正確版本的業務庫。我很確定這是不可能的,所以我繼續討論主要問題。

有沒有一種優雅的方式來檢測版本不兼容?理想情況下,我想要一個構建時間解決方案,否則早期運行時解決方案就沒問題。

我試過在Maven中使用版本範圍,但由於Maven如何對非標準版本格式的版本進行排序,導致我們遇到很多問題,而且在構建時正確解析範圍時出現了各種問題。

+0

「不兼容」,你是否只是指不同的版本,或實際的破損? – 2012-03-01 15:10:25

+0

@DaveNewton:在這一點上或者兩者都有。我只是在尋找最少的驚喜的解決方案。 – 2012-03-01 16:15:29

回答

4

The Ning dependency-versions-check如果一個依賴版本意外被另一個依賴關係阻止,Maven插件將會失敗。它不會爲你修復它,但它至少會告訴你!

+0

這裏的問題是,它需要消費應用程序才能包含該插件。也許它可以添加到一個標準的CI環境構建。我擔心這可能會破壞其他依賴性,這些依賴性可以使用更新的版本。儘管如此,我仍然有很多需要閱讀的文檔。 – 2012-03-01 18:02:15

+0

我們將它包含在我們所有項目繼承的「基礎」pom中,因此所有項目都可以獲得它(以及其他配置)。 – 2012-03-01 19:35:24

+0

至於版本控制,它假定您有一個實際遵循的明智版本策略(例如major。 minor.patch),所以它會讓你從1.7.2回到1.7.1,但不會回到1.6.9 – 2012-03-01 19:35:53

0

我不知道有什麼方法可以做到這一點 - 無論是在運行時還是在構建時。在沒有調查清單或jar文件名的情況下,沒有用於確定軟件包版本的標準機制 - 這最多隻會是黑客攻擊。也許有一個maven插件,我不知道這是否自動這樣做,但我不知道一個。

我們只是修復了我們需要用於代碼的庫的版本,並在需要時進行升級,因爲我們需要附加功能或其他依賴項。通常我們是領先於其他的依賴,所以我們把一個典型的排斥標誌物的依賴定義在pom.xml

<dependency> 
    <groupId>org.springframework</groupId> 
    <artifactId>spring</artifactId> 
    <version>${spring-version}</version> 
    <exclusions> 
     <exclusion> 
      <groupId>commons-logging</groupId> 
      <artifactId>commons-logging</artifactId> 
     </exclusion> 

這使我們能夠依賴於版本的commons-logging

但是,如果您正在使用某個庫的1.0版本,但其中一個依賴項正在使用2.0,那麼您將不得不嘗試exclusion並查看該依賴項是否以1.0運行 - 或者甚至編譯。如果沒有,那麼你將被迫升級你的代碼以使用2.0或降級依賴。

對不起,我沒有更多的幫助。