问题描述
在多项目构建中，似乎有几种构造父pom的方法，我想知道是否有人对每种方式的优点/缺点有什么想法.
There seem to be several ways to structure parent poms in a multiproject build and I wondering if anyone had any thoughts on what the advantages / drawbacks are in each way.
拥有父pom的最简单方法是将其放在项目的根目录下，即
The simplest method of having a parent pom would be putting it in the root of a project i.e.
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xml
其中pom.xml既是父项目，又描述了-core -api和-app模块
where the pom.xml is both the parent project as well as describes the -core -api and -app modules
下一个方法是将父级分离到自己的子目录中，如
The next method is to separate out the parent into its own subdirectory as in
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
父pom仍包含模块但它们是相对的，例如../myproject-core
Where the parent pom still contains the modules but they're relative, e.g. ../myproject-core
最后，有一个选项，其中模块定义和父级分开，如
Finally, there's the option where the module definition and the parent are separated as in
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
pom.xml
父pom包含任何共享"配置(dependencyManagement，属性等)，而myproject/pom.xml包含模块列表.
Where the parent pom contains any "shared" configuration (dependencyManagement, properties etc.) and the myproject/pom.xml contains the list of modules.
意图是可扩展到大规模构建，因此应可扩展到大量项目和工件.
The intention is to be scalable to a large scale build so should be scalable to a large number of projects and artifacts.
一些奖励问题:
- 在哪里定义各种共享配置的最佳位置，如源代码控制，部署目录，通用插件等.(我假设是父级，但我经常为此而被咬住，并且最终在每个版本中项目而不是普通项目).
- maven-release插件hudson和nexus如何处理您如何设置多项目(可能是一个很大的问题，更多的人是什么时候被如何设置多项目构建所困住的)?
每个子项目都有自己的pom.xml，为了使内容简洁，我将其省略.
Each of the sub projects have their own pom.xml, I've left it out to keep it terse.
推荐答案
在我看来，要回答此问题，您需要考虑项目生命周期和版本控制.换句话说，父pom是否有其自己的生命周期，即它可以与其他模块分开发布吗?
In my opinion, to answer this question, you need to think in terms of project life cycle and version control. In other words, does the parent pom have its own life cycle i.e. can it be released separately of the other modules or not?
如果答案是是(在问题或注释中提到的大多数项目都是这种情况)，则父pom需要来自VCS和来自VCS的自己的模块.从Maven的角度来看，您将在VCS级别上得到如下结果:
If the answer is yes (and this is the case of most projects that have been mentioned in the question or in comments), then the parent pom needs his own module from a VCS and from a Maven point of view and you'll end up with something like this at the VCS level:
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
`-- projectA
|-- branches
|-- tags
`-- trunk
|-- module1
| `-- pom.xml
|-- moduleN
| `-- pom.xml
`-- pom.xml
这使结帐有点痛苦，而处理该问题的常用方法是使用svn:externals.例如，添加一个trunks目录:
This makes the checkout a bit painful and a common way to deal with that is to use svn:externals. For example, add a trunks directory:
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
|-- projectA
| |-- branches
| |-- tags
| `-- trunk
| |-- module1
| | `-- pom.xml
| |-- moduleN
| | `-- pom.xml
| `-- pom.xml
`-- trunks
具有以下外部定义:
parent-pom http://host/svn/parent-pom/trunk
projectA http://host/svn/projectA/trunk
trunks的检出将导致以下局部结构(模式2):
A checkout of trunks would then result in the following local structure (pattern #2):
root/
parent-pom/
pom.xml
projectA/
(可选)您甚至可以在trunks目录中添加pom.xml:
Optionally, you can even add a pom.xml in the trunks directory:
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
|-- projectA
| |-- branches
| |-- tags
| `-- trunk
| |-- module1
| | `-- pom.xml
| |-- moduleN
| | `-- pom.xml
| `-- pom.xml
`-- trunks
`-- pom.xml
此pom.xml是一种伪" pom:从未发布，它不包含真实版本，因为此文件从未发布，它仅包含模块列表.对于此文件，签出将导致此结构(模式3):
This pom.xml is a kind of "fake" pom: it is never released, it doesn't contain a real version since this file is never released, it only contains a list of modules. With this file, a checkout would result in this structure (pattern #3):
root/
parent-pom/
pom.xml
projectA/
pom.xml
此"hack"允许在签出后从根目录启动反应堆构建，并使事情变得更加方便.实际上，这就是我喜欢为大型构建设置Maven项目和VCS存储库的方式:它可以正常工作，可以很好地扩展，并且可以提供您可能需要的所有灵活性.
This "hack" allows to launch of a reactor build from the root after a checkout and make things even more handy. Actually, this is how I like to setup maven projects and a VCS repository for large builds: it just works, it scales well, it gives all the flexibility you may need.
如果答案为否(回到最初的问题)，那么我认为您可以使用模式1(做可能可行的最简单的事情).
If the answer is no (back to the initial question), then I think you can live with pattern #1 (do the simplest thing that could possibly work).
现在，关于奖金问题:
老实说，我不知道如何在这里不给出一个一般性的答案(例如使用您认为有意义的层次来使事物相互关联").而且无论如何，子poms始终可以覆盖继承的设置.
Honestly, I don't know how to not give a general answer here (like "use the level at which you think it makes sense to mutualize things"). And anyway, child poms can always override inherited settings.
我使用的设置效果很好，没有什么特别需要提及的.
The setup I use works well, nothing particular to mention.
实际上，我想知道maven-release-plugin如何处理模式#1(尤其是<parent>部分，因为在发布时您没有SNAPSHOT依赖项).这听起来像是鸡肉或鸡蛋的问题，但我只是不记得它是否有效并且懒得测试它.
Actually, I wonder how the maven-release-plugin deals with pattern #1 (especially with the <parent> section since you can't have SNAPSHOT dependencies at release time). This sounds like a chicken or egg problem but I just can't remember if it works and was too lazy to test it.
这篇关于Maven父POM与模块POM的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！