如何在多模块项目中处理Maven版本? [英] How to handle maven versions in a multi module project?
问题描述
我有一个像这样的Maven项目基础架构:
I have a maven project infrastructure like this:
/trunk/all/pom.xml
/trunk/all/libs/lib1/pom.xml
/lib2/pom.xml
...
/trunk/all/projects/p1/pom.xml
/p2/pom.xml
...
您知道，我有很多库，并且有很多使用这些库的项目.
You see, I have a lot of libraries and a lot of projects using these libraries.
所有这些都组合到一个多模块项目中，因为我喜欢
All this is combined to one multi module project, because I like to
- 将顶级项目导入eclipse，并立即使我所有的库和项目可用
- 完成一些全局重构后，只执行一个
mvn test即可编译和测试我的所有代码.
- import the top project into eclipse and have all my libraries and projects available at once
- only do a single
mvn testto compile and test all my code after I've done some global refactorings.
当前，我所有的模块均为版本1.0-SNAPSHOT.
Currently, all my modules are version 1.0-SNAPSHOT.
现在我要发布项目p2，所有库p2使用(例如lib1和lib2)到版本1.0.之后，我在lib1上进行了一些代码修改，但在lib2上进行了无操作.
Now I want to release project p2 and all libs p2 uses (e.g. lib1 and lib2) to version 1.0. After that I do some code modifications on lib1, but none on lib2.
我希望下一个版本的p2是版本1.1，使用版本1.1中的lib1(自上一发行版以来已对其进行了修改)，但是lib2仍处于版本1.0中(因为它没有被修改).
I want the next release of p2 being version 1.1, using lib1 in version 1.1 (it was modified since the last release), but lib2 still in version 1.0 (since it wasn't modified).
更笼统:如果我要发布，我想增加自上次发布以来正在发布的项目以及所有已更改库的次要数量.
More general: If I do a release, I want to increase the minor numbers of the project being released and of all changed libraries since the last release.
我是否必须自己照顾所有模块版本，还是有一个插件可以为我完成所需的工作?
Do I have to take care for all the module versions by myself or is there a plugin that is able to do the required work for me?
推荐答案
我是否必须自己照顾所有模块版本，还是有一个插件可以为我完成所需的工作?
Do I have to take care for all the module versions by myself or is there a plugin that is able to do the required work for me?
好吧，如果您不想使各种工件(项目，库)的版本与all/pom.xml中定义的版本保持同步(即仅继承整个层次结构)，恐怕您将不得不开始手动管理它们.我只是不确定要理解为什么即使您不对其进行任何更改，您也不会颠覆lib2的版本.在您当前的svn存储库结构中，所有工件都以某种方式具有相同的发布生命周期(当您标记中继时，您将标记其中的所有内容).
Well, if you don't want to keep the versions of the various artifacts (projects, libs) in sync with the version defined in all/pom.xml (i.e. just inherit it through the whole hierarchy), I'm afraid you'll have to start to manage them manually. I'm just not sure to understand why you wouldn't bump the version of say lib2 even if you didn't make any change to it. With your current svn repository structure, all artifacts have the same release lifecycle somehow (when you'll tag the trunk, you'll tag everything in it).
现在，如果p1和p2(为简单起见，我将忽略这些库)具有独立的发布周期，那么我建议您使用多个主干/标签/分支" "此线程:
Now, if p1 and p2 (I'll ignore the libs for the sake of simplicity) have an independent release cycle, I would recommend a multiple "trunk/tags/branches" structure as described in this thread:
myrepo
+ .links (2)
+ trunks
+ pom.xml
+ parent-pom (1)
+ trunk
+ pom.xml
+ project-A
+ trunk
+ pom.xml
+ project-B
+ trunk
+ pom.xml
1)项目的父POM具有
自己的发布周期.每一个
组件的POM将其用作父对象
(仅用groupId和
artifactId，否relativePath).为了
发布，您必须发布
父POM首先.
1) The parent POM of the project has
an own release cycle. Every
component's POM will use it as parent
(referenced simply with groupId and
artifactId, no relativePath). For
a release you'll have to release the
parent POM first.
2)这是启用的构造
轻松检出特定分支
项目的范围，即通常
树干.一个Subversion用户检出
myrepo/.links/trunk抢先一步
修改所有资料.诀窍是
该目录包含
外部链接(即与
svn:externals 属性)
此其他所有模块的主干
项目(父pom，项目A，
项目B).在这里的pom.xml
目录从不释放，它
仅包含用于的模块部分
这三个模块可以实现多种
模块构建.有了这个构造
您可以轻松设置分支
例如:
2) This is a construction to enable
easy check outs of a specific branch
of the project i.e. normally the
trunk. A subversion user checks out
myrepo/.links/trunk to get the head
revision of all sources. The trick is,
that that directory contains
external links (i.e. with the
svn:externals property) to the
trunks of all other modules of this
project (parent-pom, project-A,
project-B). The pom.xml in this
directory is never released, it
contains simply a modules section for
the three modules to enable a multi
module build. With this construct
you're able to setup easily branches
e.g.:
myrepo
+ .links
+ branch-2.x
+ pom.xml
我已经多次使用了这个设置(我已经在SO上写过它了，请参阅下面的相关问题)，它工作得很好.实际上，包括Maven在内的许多项目都在使用这种方法，这不是一种幻想.
I've used this setup many times (I already wrote about it here on SO, see the related questions below), it works very well. Actually, many projects, including Maven, are using this approach, it's not a fantasy one.
这不会解决您的自动"版本处理问题(我不知道有什么解决方案)，但至少，此结构与
This will not solve your "automagic" version handling (I don't know any solution for that) but at least, this structure plays nicely with the Maven Release Plugin and would support your independent release cycle requirements.
- Building Maven
- XWiki Platform Structure
- Cargo SVN
- Maven parent pom vs modules pom
- Migrating to maven from an unusual svn directory structure?
这篇关于如何在多模块项目中处理Maven版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
