Maven 父 pom 与模块 pom [英] Maven parent pom vs modules pom

查看:122
本文介绍了Maven 父 pom 与模块 pom的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

似乎有几种方法可以在多项目构建中构建父 poms,我想知道是否有人对每种方式的优点/缺点有任何想法.

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 包含任何共享"配置(依赖管理、属性等),而 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 和来自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.

  • maven-release 插件、hudson 和 nexus 如何处理你如何设置你的多项目(可能是一个巨大的问题,如果有人被多项目构建的设置方式所吸引,那就更重要了)?

我使用的设置效果很好,没什么特别值得一提的.

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的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆