Maven 2项目版本、依赖版本和永久发布

尝试布局您的构建,以便需要一起开发的模块一起发布。这将让maven发布插件为您完成大部分工作。

对于确实应该有单独生命周期的依赖项…因为它们很少更改或由多个项目共享,所以您希望以不同的方式处理它们。我这样做的方式是将依赖项保留在上一个发布版本,直到更改实际需要升级到下一个快照。通过这种方式,当您发布产品时,您将发现所有可能也会发布的内容,只需遵循快照跟踪即可。

我发现将外部依赖版本指定为项目顶部pom中的属性也很有帮助。这使得我们很容易一目了然地看到需要发布的内容。寻找一个例子 Nexus 波姆。

对于maven和内部项目,这是一件非常困难的事情;您有两个版本控制系统(maven的,坦率地说,它不是很好)和源代码控制系统(假设它是CVS或更好,它支持真正的工作流)。

我们是这样做的:

report --depends on--> core
web    --depends on--> core

我们使用maven释放塞:

在开发过程中,报表的pom将有一个快照版本,与core的pom中的内容相匹配。我做一个 mvn clean install 在core中,我可以看到 report 在我当地的环境中。

mvn release:prepare 如果你愿意的话)。

web上的开发人员随后收到一封电子邮件,告知有新版本的core可用,如果他们愿意,他们可以选择使用它。我们的政策是,他们应该在发布之前更新。

dependency classifier 可能是值得研究的事情。您仍然需要有能够正确识别其修改代码的开发人员。

我们使用一个“Super Parent.pom”项目,在该项目中,版本被定义为属性,在每个child.project中,版本都使用这些属性设置

此外,实际项目没有版本集,而是从其父pom项目(包括groupId等)继承它

e、 g.这一结构

• 超级父级pom项目(定义为属性的所有第三方版本,例如2.5.6 spring framework) ----持久化父级pom项目,从超级父级继承所有 ------持久化foobar jar项目,从持久化父级继承所有 ----util父项

等

您看到的唯一版本是父关系中的版本

        <modelVersion>4.0.0</modelVersion>
<artifactId>foo-bar-foo</artifactId>
<packaging>jar</packaging>
<name>whatever</name>
<description>...</description>
<parent>
    <groupId>org.foo.bar</groupId>
    <artifactId>persistence-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>foo-bar</artifactId>
        <version>${project.version}</version>
    </dependency>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>foo-bar</artifactId>
        <version>${project.version}</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>org.springframework.jdbc</artifactId>
        <version>${parent.spring.version}</version>
    </dependency>

它是这样工作的,因为在pom中,您可以使用已经定义的值,例如version,即使版本是通过继承设置的

我们将其与父项目内的模块设置相结合,以使构建更容易