如何告诉Maven使用最新版本的依赖项？

我使用发布插件来执行发布,它负责-SNAPSHOT并验证是否存在-SNAPSHOT的发布版本(这很重要).

如果您按我的方式执行操作,您将获得所有快照构建的最新版本以及发布版本的最新版本.您的构建也将是可重现的.

更新

我注意到一些评论询问了这个工作流程的一些细节.我会说我们不再使用这种方法,而且maven版本插件的主要原因是错误的,并且通常存在固有的缺陷.

这是有缺陷的,因为要运行版本插件来调整版本,所有现有版本都需要存在才能使pom正确运行.这是版本插件无法更新到任何东西的最新版本,如果它找不到pom中引用的版本.这实际上相当烦人,因为我们经常为磁盘空间原因清理旧版本.

真的,您需要maven的单独工具来调整版本(因此您不依赖于pom文件才能正确运行).我用低级语言Bash编写了这样一个工具.该脚本将更新版本插件等版本,并将pom检入源控件.它的运行速度比mvn版本插件快100倍.不幸的是,它不是以公共使用的方式编写的,但是如果人们感兴趣我可以这样做,并把它放在gist或github中.

回到工作流程,因为一些评论询问我们这是我们做的:

我们在他们自己的存储库中有20个左右的项目,他们有自己的jenkins工作

当我们发布maven release插件时使用.该工作流程包含在插件的文档中.maven发布插件很糟糕(而且我很善良)但它确实有效.有一天,我们计划用更优化的方法替换这种方法.

当其中一个项目发布时,jenkins然后运行一个特殊的工作,我们将调用更新所有版本的工作(jenkins如何知道它的发布是一种复杂的方式,因为maven jenkins发布插件也非常糟糕).

更新所有版本的作业都知道所有20个项目.它实际上是一个聚合器pom,它特定于依赖顺序的模块部分中的所有项目.Jenkins运行我们的魔法groovy/bash foo,将所有项目更新到最新版本,然后签入poms(再次按照依赖顺序基于模块部分完成).

对于每个项目,如果pom已更改(由于某些依赖项中的版本更改),则会检入并然后立即ping jenkins以运行该项目的相应作业(这是为了保留构建依赖性顺序,否则您将受到限制SCM轮询调度程序).

在这一点上,我认为将版本和自动版本作为一般构建的单独工具是一件好事.

现在你可能认为maven有点糟糕,因为上面列出的问题但实际上这对于没有声明易于解析的可扩展语法(又称XML)的构建工具来说相当困难.

实际上,我们通过命名空间添加自定义XML属性来帮助提示bash/groovy脚本(例如,不要更新此版本).

依赖关系语法位于依赖关系版本要求规范文档中.这是为了完整性:

依赖关系version元素定义版本要求,用于计算有效的依赖关系版本.版本要求具有以下语法:

1.0:1.0上的"软"要求(只是推荐,如果它匹配依赖项的所有其他范围)

[1.0]:1.0上的"硬"要求

(,1.0]:x <= 1.0

[1.2,1.3]:1.2 <= x <= 1.3

[1.0,2.0):1.0 <= x <2.0

[1.5,):x> = 1.5

(,1.0],[1.2,):x <= 1.0或x> = 1.2; 多个集以逗号分隔

(,1.1),(1.1,):这不包括1.1(例如,如果知道不与此库结合使用)

在你的情况下,你可以做类似的事情 [1.2.3,)

您是否可能依赖于在开发过程中显然会发生很大变化的开发版本？

您可以使用在必要时覆盖的快照版本,而不是增加开发版本的版本,这意味着您不必在每次微小更改时更改版本标记.像1.0-SNAPSHOT ......

但也许你正在努力实现其他目标;)

当提出这个问题时,maven中有一些版本范围存在问题,但这些问题已经在较新版本的maven中得到解决.本文非常清楚地介绍了版本范围的工作原理和最佳实践,以便更好地了解maven如何理解版本:https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

谁曾使用LATEST,请确保你有-U否则不会拉最新的快照.

mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST
// pull the latest snapshot for my-foo from all repositories

事实是，即使在3.x中它仍然可以工作，令人惊讶的是，这些项目可以构建和部署。但是LATEST / RELEASE关键字在m2e中引起问题，并使整个地方都黯然失色，ALSO项目依赖于通过LATEST / RELEASE部署的依赖项无法识别版本。

如果尝试将版本定义为属性，并在其他位置引用它，也会引起问题。

因此，结论是，如果可以，请使用versions-maven-plugin。

有时您不想使用版本范围，因为它们似乎很“缓慢”地解决了您的依赖性，尤其是在持续交付且有大量版本的情况下-主要是在繁重的开发过程中。

一种解决方法是使用versions-maven-plugin。例如，您可以声明一个属性：

    1.1.1

并将versions-maven-plugin添加到您的pom文件中：

    
        
            org.codehaus.mojo
            versions-maven-plugin
            2.3
            
                
                    
                        myname.version
                        
                            
                                group-id
                                artifact-id
                                latest
                            
                        
                    
                
            
        
    

然后，为了更新依赖关系，您必须执行目标：

mvn versions:update-properties validate

如果存在比1.1.1更高的版本，它将告诉您：

[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2