如何重组Maven多模块项目？ [英] How to restructure Maven multi-module project?

问题描述

我为这篇文章的篇幅感到抱歉，但是如果没有展示图片，我就很难让它更简洁。我最近继承了maven 3.0多模块项目的build-master的工作。问题是项目/模块的结构是一场灾难。从事物当前存储在源代码管理（我们使用RTC）到模块的pom结构的方式，我正在试图让每次完成一个完整的构建周期。

当项目层次结构出现时，所有模块都存储为平面;即：一切都处于同一水平。我有一个父pom，所有模块都依赖于父。但是，父母与我所有其他模块处于同一水平。

Ex：

  c：\dev \ MyEarProject 
 + parent-pom 
  -  pom.xml 
 + module1 
  -  pom.xml（取决于parent-pom） ）
  -  src 
  - 主
  -  ... 
 + module2 
  -  pom.xml（取决于父pom）
  -  src 
  - 主
  -  ... 
 + module3 
  -  pom.xml（取决于父母pom）
  -  src 
  - 主
  - ... 
  

父pom定义了构建项目所需的所有模块，以及一堆整个不同子模块中使用的工件版本号的属性：

 < modules> 
< module> ../ module1< / module> 
< module> ../ module2< / module> 
< module> ../ module3< / module> 
< / modules> 
 
< properties> 
< org.springframework.version> 3.0.5.RELEASE< /org.springframework.version> 
< slf4j.version> 1.6.4< /slf4j.version> 
< repositoryAddress> $ {snapshots.repo.url}< / repositoryAddress> 
< my.hibernate-module.dao.impl> 1.2.3< /my.hibernate-module.dao.impl> 
< my.hibernate-module.dao.api> 1.2.3< /my.hibernate-module.dao.api> 
< / properties> 
  

每个模块的pom依次通过pom的工件编号依赖于父pom：

 < parent> 
< groupId> com.cws.cs.lendingsimulationservice< / groupId> 
< artifactId> parent-pom< / artifactId> 
< version> 1.0.6< / version> 
< / parent> 
  

为了让事情更加混乱，实际的工件名称可能会或可能不会（取决于模块） ），匹配模块路径。例如，module1可能位于路径 c：\ dev \ MyEarProject \module1 中，但具有工件名称 hibernate-module 。但是，由于它存储在RTC中的方式，目录在签出时被称为 module1 。

<当然，构建所有内容的最简单方法是进入 c：\dev \ MyEarProject \ parent-pom \ 并运行 mvn clean deploy 。这在SNAPSHOT模式下工作正常，因为SNAPSHOT repo允许多个部署相同的工件版本。但在发布模式下，这会失败。

此结构对我造成2个问题。

1. 每次我需要对父级中的属性进行版本更改时，我必须更新父pom版本号，并更新所有子模块父pom的版本，以及所有子模块版本本身（因为父级）


2. 每当我需要部署一个发布周期时，如果其中一个模块自上一个周期以来没有改变，则mvn将抛出错误，因此无法重新部署到同一个repo（ repo不允许覆盖现有的工件）

所以我正在寻找重组这个项目的最佳方法来避免这些问题。对于父pom，我知道我可以使用相对路径指向父代。但是，考虑到模块的扁平结构，这是一种推荐的方法（即：父pom相对路径是../parent-pom/pom.xml - 对我来说似乎有点奇怪）？另外，鉴于父版本的版本控制独立于模块，使用相对路径不仅会打开额外混淆的大门（即：无法知道哪个版本的父pom与哪个版本相关联子模块）。

其次，如何在不遇到我所遇到的部署错误的情况下构建整个耳朵？由于工件已存在于repo中，因此我无需重建和重新部署它。我尝试使用--projects但是涉及的模块数量很难管理。

解决方案

我第一件事真的建议重组项目文件夹...这意味着让projects文件夹代表结构，这意味着 NOT 展平结构。

  +  -  parent-pom（pom.xml）
 + --- module1（pom.xml）
 + --- module2（pom.xml）
 + --- module3（pom.xml）
  

由于模块部分你的父母将被简化为：

 < modules> 
< module> module1< / module> 
< module> module2< / module> 
< module> module3< / module> 
< / modules> 
  

此外，模块中的父条目可以简化为：

 < parent> 
< groupId> com.cws.cs.lendingsimulationservice< / groupId> 
< artifactId> parent-pom< / artifactId> 
< version> 1.0.6< / version> 
< / parent> 
  

...这让我想到下一点：

如果您当前的所有项目都定义了他们的父项，这是完全错误的，因为将尝试在存储库中找到父级而不是在上级文件夹中。换句话说，这会导致你发布大量等问题。

如果我们要修复这个问题，它必须看起来像我不能推荐的那样：

 < parent> 
< groupId> com.cws.cs.lendingsimulationservice< / groupId> 
< artifactId> parent-pom< / artifactId> 
< version> 1.0.6< / version> 
< relativePath> ../ parent-pom / pom.xml< / relativePath> 
< / parent> 
  

我观察到的另一件事是你不使用 SNAPTSHOT 将在发布阶段由发布插件替换。与此相关，它将自动更改相应父母等中的所有版本。

在理想情况下，您的模块应如下所示：

 < parent> 
< groupId> com.cws.cs.lendingsimulationservice< / groupId> 
< artifactId> parent-pom< / artifactId> 
< version> 1.0.6< / version> 
< / parent> 
 
< artifactId> module-1< / artifactId> 
<！ -  No Version或groupId  - > 
  

因为所有模块都将继承版本并且 groupId 来自他们的父母。有时它是有用的或需要更改模块 groupId 但它是一个例外。

关于我重读的事情是关于父母的单独版本。这根本没有意义，因为它是模块的父级，所以把它放到相同的结构中，当然也就是相同的VCS。

如果你想做一些配置/ plugins版本，应该用于其他项目的依赖项，而不是单独的公司 pom.xml 这是一个单独的项目，将单独发布等。

完成结构更改后，您只需进入parent-pom目录并执行 mvn clean package 或 mvn release：prepare release：从该文件夹执行，一切都会更简单。

I appologize for the length of this post, but I had trouble making it more concise without presenting the picture. I've recently inherited the job of build-master for a maven 3.0 multi-module project. The problem is that the structure of the project/modules is a disaster. From the way things are currently stored in Source Control (we use RTC) to the pom structure of the modules, I'm tearing my hair out trying to get a full build cycle completed each time.

As a project hierarchy goes, all the modules are stored "flat"; ie: everything is at the same level. I have a parent pom, and all modules depend on the parent. However, the parent is at the same level as all my other modules.

Ex:

c:\dev\MyEarProject
 + parent-pom
   - pom.xml
 + module1
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module2
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module3
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...

The parent pom defines all the modules required to build the project, as well as a bunch of properties for artifact version numbers used throughout the different submodules:

<modules>
  <module>../module1</module>
  <module>../module2</module>
  <module>../module3</module>
</modules>

<properties>
    <org.springframework.version>3.0.5.RELEASE</org.springframework.version>
    <slf4j.version>1.6.4</slf4j.version>
    <repositoryAddress>${snapshots.repo.url}</repositoryAddress>
    <my.hibernate-module.dao.impl>1.2.3</my.hibernate-module.dao.impl>
    <my.hibernate-module.dao.api>1.2.3</my.hibernate-module.dao.api>
</properties>

Each module's pom, in turn, depends on the parent pom via the pom's artifact number:

<parent>
    <groupId>com.cws.cs.lendingsimulationservice</groupId>
    <artifactId>parent-pom</artifactId>
    <version>1.0.6</version>
</parent>

To make things even more confusing, the actual artifact name may, or may not (depending on the module), match the module path. For example, module1 may be located in path c:\dev\MyEarProject\module1 but have artifact name hibernate-module. However, due to the way it is stored in RTC, the directory is called module1 when it is checked-out.

The easiest way to build everything, of course, is to go into c:\dev\MyEarProject\parent-pom\ and run mvn clean deploy. This works fine when in SNAPSHOT mode as the SNAPSHOT repo allows for multiple deployments of the same artifact version. But in release mode, this fails.

This structure is causing 2 problems for me.

1. Everytime I need to make a version change to a property in the parent, I have to update the parent-pom version number, and all the child modules parent pom's version, and all the child modules version themselves (since the parent changed).
2. Whenever I need to deploy a release cycle, mvn will throw an error if one of the modules has not changed since the last cycle and consequently cannot be redeployed to the same repo (the repo does not allow overwriting existing artifacts)

So I'm looking for the best way to restructure this project to avoid these problems. For the parent pom, I know I can use a relative path to point to the parent instead. However, given the "flat" structure of the modules, is this a recommended approach (ie: the parent pom relative path would be ../parent-pom/pom.xml - seems a little odd to me)? Additionally, given that the versioning control of the parent is independent of the modules, would using a relative path not just open the door to additional confusion (ie: there would be no way to know which version of the parent pom is associated with which version of the submodule).

Secondly, how can I build the entire ear without encountering the deploy errors I am having? Since the artifact already exists in the repo, I don't need to rebuild and redeploy it. I tried using --projects but with the number of modules involved, it gets extremely difficult to manage.

解决方案

The first thing I really recommend is to restructure the projects folders ...which means to have the projects folder represent the structure which means NOT flatten the structure.

  +-- parent-pom (pom.xml)
       +--- module1 (pom.xml)
       +--- module2 (pom.xml)
       +--- module3 (pom.xml)

As a result of that the modules section your parent will be simplified like this:

<modules>
  <module>module1</module>
  <module>module2</module>
  <module>module3</module>
</modules>

Furthermore the parent entries in your modules can be simplified as well like this:

<parent>
  <groupId>com.cws.cs.lendingsimulationservice</groupId>
  <artifactId>parent-pom</artifactId>
  <version>1.0.6</version>
</parent>

...which brings me to the next point:

If all your current project define their parent as above this is simply wrong, cause will try to find the parent within the repository and not in a upper level folder. In other words this is causing of much of your problems with releasing etc.

If we would fix this problem it has to look like this which I can't recommend:

<parent>
  <groupId>com.cws.cs.lendingsimulationservice</groupId>
  <artifactId>parent-pom</artifactId>
  <version>1.0.6</version>
  <relativePath>../parent-pom/pom.xml</relativePath>
</parent>

An other thing which I observe is that you don't use SNAPTSHOT's which will be replaced by the release plugin during the release phase. And in relationship to that it will automatically change all versions in the appropriate parents etc.

In ideal case your modules should look like this:

<parent>
  <groupId>com.cws.cs.lendingsimulationservice</groupId>
  <artifactId>parent-pom</artifactId>
  <version>1.0.6</version>
</parent>

<artifactId>module-1</artifactId>
<!-- No Version or groupId -->

Cause all modules will inherit the version and groupId from their parent. Sometimes it's useful or needed to change a modules groupId but it's an exception.

On thing I reread is about the separate versioning of the parent. This simply does not make sense, cause it's the parent of their modules so put it into the same structure and of course the same VCS.

If you want to make some configuration/plugins versions, dependencies which should be used for other projects as well than make a separate corporate pom.xml which is a separate project and will be separately released etc.

After you finished your structure changes you can simply go into the parent-pom directory and do mvn clean package or mvn release:prepare release:perform from that folder and everything will simpler.

这篇关于如何重组Maven多模块项目？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！