Maven家长pom vs模块pom
似乎有多种方法可以在多项目构建中构建家长团队,我想知道是否有人对每种方式的优点/缺点有什么想法。
有一个父pom的最简单的方法将把它放在一个项目的根,即
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xml
其中pom.xml既是父项目,也描述了-core -api和-app模块
下一个方法是将父项分离到其自己的子目录中
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
父pom仍然包含模块,但它们是相对的,例如../myproject-core
最后,还有一个选项,即模块定义和父项分开
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
pom.xml
父pom包含任何“共享”配置(dependencyManagement,属性等),myproject / pom.xml包含模块列表。
目的是扩展到大规模的构建,因此应该可扩展到大量的项目和工件。
一些奖励问题:
编辑:每个子项目都有自己的pom.xml文件,我已经把它保留下来以保持简洁。
在我看来,要回答这个问题,你需要考虑项目生命周期和版本控制。 换句话说,父pom是否有自己的生命周期,即它可以与其他模块分开发布吗?
如果答案是肯定的 (这就是问题中或评论中提到的大多数项目的情况),那么父pom需要从VCS和Maven的角度来看他自己的模块,最终你会在VCS级别有这样的事情:
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
`-- projectA
|-- branches
|-- tags
`-- trunk
|-- module1
| `-- pom.xml
|-- moduleN
| `-- pom.xml
`-- pom.xml
这使得结账有点痛苦,并且处理这个问题的常用方法是使用svn:externals
。 例如,添加一个trunks
目录:
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):
root/
parent-pom/
pom.xml
projectA/
或者,你甚至可以添加pom.xml
在trunks
目录:
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):
root/
parent-pom/
pom.xml
projectA/
pom.xml
这个“黑客”允许在结账后从根启动反应堆构建,使事情变得更加方便。 实际上,这就是我喜欢为大型构建设置Maven项目和VCS存储库的方法:它可以正常工作,可以很好地扩展,它提供了您可能需要的所有灵活性。
如果答案是否定的 (回到最初的问题),那么我认为你可以接受模式#1(做最简单的事情,可能会工作)。
现在,关于奖金问题:
老实说,我不知道如何在这里不给出一个普遍的答案(比如“使用你认为合理的水平来使事物相互作用”)。 无论如何,子poms总是可以覆盖继承的设置。
我使用的设置效果很好,没有什么特别要提到的。
实际上,我想知道maven-release-plugin是如何处理模式#1的(特别是对于<parent>
部分,因为在发布时不能有SNAPSHOT依赖关系)。 这听起来像一个鸡或鸡蛋的问题,但我不记得它是否有效,并且懒得测试它。
根据我的经验和Maven的最佳实践,有两种“父母”
“company”parent pom - 这个pom包含你的公司特定信息和配置,它继承了每一个pom并且不需要被复制。 这些信息是:
准备这个父类pom需要谨慎对待,因为你所有的公司poms都会继承它,所以这个pom必须是成熟和稳定的(发布一个父pom版本不应该影响你的所有公司项目的发布!)
目的是扩展到大规模的构建,因此应该可扩展到大量的项目和工件。
Mutliprojects具有树的结构 - 所以你不会落到父母的一个层次上。 尝试为您的需求找到合适的项目结构 - 一个典型的例子是如何分解mutimodule项目
distibution/
documentation/
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xml
pom.xml
一些奖励问题:
这种配置必须明智地分解为“公司”母公司和项目母公司。 与您所有项目相关的事情都转到“公司”父项目,并且与当前项目相关的项目将投入项目。
公司母公司必须首先发布。 对于多项目,适用标准规则。 CI服务器需要知道所有才能正确构建项目。
独立的父母是跨其他未耦合组件共享配置和选项的最佳实践。 Apache有一个母公司pom项目来分享法律声明和一些常见的包装选项。
如果您的顶级项目具有真正的功能,例如聚合javadoc或打包发布,那么您在执行该工作所需的设置与想要通过父级共享的设置之间会产生冲突。 一个只有父母的项目避免了这一点。
一个常见的模式(暂时忽略#1)是项目代码使用一个父项目作为他们的父项,并使用顶层作为父项。 这允许所有人共享核心内容,但避免了#2中描述的问题。
如果父级结构与目录结构不同,则该网站插件会变得非常混乱。 如果你想建立一个聚合网站,你需要做一些摆弄来解决这个问题。
Apache CXF就是#2模式的一个例子。
上一篇: Maven parent pom vs modules pom
下一篇: Maven doesn't recognize sibling modules when running mvn dependency:tree