Maven 2 如何在多模块项目中处理maven版本？

我有一个maven项目基础架构，如下所示：

/trunk/all/pom.xml
/trunk/all/libs/lib1/pom.xml
               /lib2/pom.xml
               ...
/trunk/all/projects/p1/pom.xml
                   /p2/pom.xml
                   ...

你看，我有很多库和很多使用这些库的项目

所有这些结合到一个多模块项目中，因为我喜欢

• 将top项目导入eclipse，让我的所有库和项目同时可用
• 在完成一些全局重构后，只需执行一次

  mvn测试

  ，即可编译和测试所有代码

目前，我的所有模块都是版本

1.0-SNAPSHOT

现在我想将project

p2

和所有LIB

p2

使用（例如

lib1

和

lib2

）发布到版本

1.0

。之后，我对

lib1

进行了一些代码修改，但对

lib2

进行了none修改

我希望下一个版本的

p2

是

1.1

，在

1.1

版本中使用

lib1

（自上一个版本以来进行了修改），但

lib2

仍在

1.0版本中（因为没有修改）

更一般：如果我发布了一个版本，我希望增加正在发布的项目的次要数量，以及自上次发布以来所有更改的库的次要数量

问题:
我是否必须自己处理所有模块版本，或者是否有插件可以为我完成所需的工作

我是否必须自己处理所有模块版本，或者是否有插件可以为我完成所需的工作

好的，如果您不想使各种工件（项目、库）的版本与
all/pom.xml
中定义的版本保持同步（即通过整个层次结构继承），恐怕您必须开始手动管理它们。我只是不太明白为什么即使您没有对say
lib2
进行任何更改，您也不会修改它。在您当前的svn存储库结构中，所有工件都以某种方式具有相同的发布生命周期（当您标记主干时，您将标记其中的所有内容）

现在，如果
p1
和
p2
（为了简单起见，我将忽略libs）有一个独立的发布周期，我建议采用多个“主干/标签/分支”结构，如所述：

1） 项目的父POM已
一个自己的发布周期。每一个
组件的POM将使用它作为父级
（仅使用
groupId
和
artifactId
，no
relativePath
）。对于
释放你必须释放
首先是父母

2） 这是一个使
特定分支的轻松签出
该项目的一部分，即通常
大旅行箱subversion用户签出
myrepo/.links/trunk获取头部
修订所有来源。诀窍是,，
该目录包含的
外部链接（即与
（财产）至
本系统所有其他模块的中继线
项目（母公司pom、项目A、，
项目B）。本文中的pom.xml
目录从未发布，它
只包含一个模块部分，用于
这三个模块用于启用多个
模块构建。用这种构造
您可以轻松地设置分支
e、 g:

我已经多次使用过这个设置（我已经在这里写过了，请参阅下面的相关问题），它工作得非常好。实际上，包括Maven在内的许多项目都在使用这种方法，这不是一种幻想

这不会解决您的“automagic”版本处理问题（我不知道任何解决方案），但至少，这种结构可以很好地满足您的独立发布周期要求

另见





相关问题



嗨！
也许我遗漏了一些东西，但是如果你的LIB/模块开始觉得有必要拥有自己的版本号，这难道不表明它们正在成长并开始自己的生活——也就是说，以自己的方式成为独立的ish项目吗

这意味着将它们视为独立的项目、推送到某个mvn回购协议，并作为正常的依赖项添加到核心项目，这可能是有意义的

很抱歉，如果我不知何故遗漏了要点，但我自己也遇到了多模块项目“问题”……也许这个问题根本不是问题？
在我的上一个项目中，我构建了一个命令行工具，可以让您自动增加或减少主选项，特定模块的次要或增量版本，同时自动更新其他模块中的所有依赖项（它理解依赖项、父项甚至工件）。使用它非常有趣，但最终我们意识到我们不需要单独的模块版本，所以我们放弃了它。很好的回答，顺便说一句（+1）@seanizer很有趣，尽管我到目前为止并不真正需要这种粒度。用Groovy编写的？：）不，纯java。也没有使用maven代码。我会看看是否能找到它并把它贴到某个地方。@pascal:谢谢你的回答，我会重新考虑我目前的目录结构。但我认为你的建议需要做更多的工作。在发布单个项目时，我用我的结构标记整个结构。这就是我要做的。模块的版本号只能让我的客户知道代码的哪一部分（哪些模块）已经更改。@tangens:不客气。我不确定你是否在使用maven发布插件，我的答案是面向maven发布插件（正如标签所建议的）。我也不太明白为什么更改模块的版本号会引起客户的关注（您可能有很好的理由，但为什么不使用发行说明？），但在我看来，转向手动版本管理与您的维护问题相冲突。每个库都有自己的生命周期。我正在寻找一种自动的方法来增加库的版本号，如果它在使用I
myrepo
  + .links (2)
    + trunks
      + pom.xml
  + parent-pom (1)
    + trunk
      + pom.xml
  + project-A
    + trunk
      + pom.xml
  + project-B
    + trunk
      + pom.xml 

myrepo
  + .links
    + branch-2.x
      + pom.xml