據this reference,Maven的要求的版本是這樣的形式:
<MajorVersion [> . <MinorVersion [> . <IncrementalVersion ] ] [> - <BuildNumber | Qualifier ]>
凡MajorVersion,MinorVersion,IncrementalVersion和BuildNumber都是數字和預選賽是一個字符串。 如果您的版本號與此格式不匹配,則整個版本號將被視爲限定符。
如果您使用的是不遵循此版本控制方案的工件,則可以解釋您可能「面臨問題」(特別是Maven版本範圍)。查看從文章鏈接的Maven source code是相當有幫助的。
在您給出的示例中,Hibernate和Spring構件在使用「.
」而不是「-
」來區分限定符時似乎有所偏差。
我的一些實驗顯示DefaultArtifactVersion
將如上所述精確地解析版本號。也就是說,考慮到春節例子(3.1.2.RELEASE
)將被解釋爲:
- 專業:
0
- 輔修:
0
- 增量:
0
- 預選賽:
3.1.2.RELEASE
更重要兩個版本號的比較(如果使用Maven 3.0或更高版本)是多更靈活。版本號分爲項目列表(其中.
或-
表示項目之間的邊界,請注意.
的優先級高於-
)。比較是通過將每個項目分期並進行自然順序比較來完成的。因此3.1.2.RELEASE
將被視爲小於3.1.3.RELEASE
。字符串也被比較,因此3.1.2.RELEASD
將被視爲小於3.1.2.RELEASE
。有跡象表明,有特殊等價一些特殊的字符串,例如3.1.3.a.1
將整理一樣3.1.3.alpha.1
然而,雖然比較是Maven中的較新版本更加靈活。版本範圍邊界仍然使用Major:Minor:Incremental:Qualifier方案進行評估,因此如果您使用版本範圍,則靈活性不太有用。
不要使用版本範圍。這是一個誘人的想法,事實證明這是一個糟糕的計劃。如果Maven允許直接列出範圍和指定版本,會更好。指定的版本將被解析,範圍將用於提供可以更新的範圍和/或範圍的範圍在運行時有效的提示。版本範圍混淆了構建時間問題和運行時問題,目前使用Maven的建議很簡單:*不要使用版本範圍* –
@Stephen我同意我認爲Maven會將構建時間依賴與運行時兼容混淆,他們確實需要一個元素,它是框架作者列表,它們與之兼容的框架,但即使如此,仍然需要穩定的方式來對版本號進行排序。例如spring security 3.1.3聲明瞭對spring 3.0.7的依賴,因爲它可以與3.0.7和3.1.2一起使用,如果你使用強制插件來強制版本收斂,那麼你必須排除spring作爲spring安全的依賴。我不使用版本範圍,我使用執行插件強制收斂。 –
ams