如何将多模块项目移动到maven

时间:2015-05-15 11:15:22

标签: java maven

我们正在尝试将多个模块应用程序移动到maven,并遇到一些问题。

每个模块都独立存储在cvs中。我们为每个应用程序提供了清单文件,列出了该应用程序所需的模块(以及可选的版本)。并非所有模块都是maven形式。

因此,应用程序'customer_care'具有以下清单:

 <manifest>
 <module id="MY_api"/>
 <module id="custcare_webapp"/>
 </manifest>

同样,应用程序“核心批次”的清单如下:

 <manifest>
 <module id="MY_api"/>
 <module id="core"/>
 <module id="batch"/><!--NB this is a non-maven module -->
 </manifest>

我已开始'mavenising'我们的代码,因此MY_api项目有一个定义了依赖项的pom.xml,包括另一个内部代码模块'central_config'。我已指定版本RELEASE。

问题

这一切都很好,直到我需要创建一个冻结的清单。我可以为每个模块指定一个版本:

 <manifest>
 <module id="MY_api" version="0.123.0"/>
 <module id="core" version="0.456.0"/>
 <module id="batch" version="0.789.0"/><!--NB this is a non-maven module -->
 </manifest>

但是这个版本不可重现,因为MY_api中'centralconfig'依赖的版本是'RELEASE'。因此,如果有人发布了新版本的“centralconfig”,那么下次我们构建这个冻结的清单时,就会有所不同。

那么为什么我们不使用像central-config这样的依赖关系的硬编码版本呢?因为那样,每当有人将centralconfig更新到新版本时,我们就必须更新10或20个pom文件。依赖于中央配置的所有东西,以及依赖于它的所有内容,都需要更新pom.xml并重新发布。这不仅是很多工作,我不知道如何以编程方式可靠地识别声明依赖于中央配置的每个模块。

可能的解决方案?

我可以在一个地方定义'centralconfig.version',然后在我的所有模块中引用它吗?如果是这样,我应该在哪里这样做?我对父母不太了解,但我觉得他们可能提供解决方案。

更新

似乎使用父pom是可行的方法。但是根据这个问题:Can maven projects have multiple parents?,maven子项目不可能有多个父母。

那么,MY_api模块如何成为custcare_webapp和core_batch的子项?

更新

我得出结论,maven不符合我的要求,我们已经回到使用我们12年的本土解决方案构建使用ant和CVS。

2 个答案:

答案 0 :(得分:2)

通常比管理版本的父结构更好的另一个选项是 import 依赖项。

为了说明这是如何工作的,你创建一个只包含pom的项目,指定用于所有模块的版本:

<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>test</groupId>
 <artifactId>module-versions</artifactId>
 <packaging>pom</packaging>
 <version>1.0</version>
 <dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>test</groupId>
       <artifactId>a</artifactId>
       <version>1.1</version>
     </dependency>
     <dependency>
       <groupId>foo</groupId>
       <artifactId>bar</artifactId>
       <version>2</version>
     </dependency>
   </dependencies>
 </dependencyManagement>
</project>

然后,在您需要依赖于任何具有硬编码版本的任何项目的项目中,您可以通过以下方式导入此项目:

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>test</groupId>
        <artifactId>module-versions</artifactId>
        <version>1.0</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

这样,您只需在发布新版本的任何依赖项时都需要更改module-versions项目。

这样你就可以拥有多个&#34;模块版本&#34; -projects来分解一些东西。

当然,您仍然遇到的问题是,所有想要使用新版本的项目也必须依次发布,但这是在Maven中使用已发布的依赖项的成本。

答案 1 :(得分:1)

我认为你确实需要父母POM。这是一个顶级pom.xml,它只是一个POM模块,没有相关的代码。您可以通过在mvn上运行pom.xml命令来构建整个项目。

POM应位于所有模块目录上方的目录中。也就是说,您的每个模块都将位于包含主文件pom.xml

的目录的子目录中

此POM的<packaging>类型将为pom。这意味着它是一个只有POM的项目,没有自己的代码。它还有一个<modules>标记,其中包含每个模块的一个<module>元素。这样,当您运行mvn命令时,Maven也会知道构建每个模块。一个体面的样本父POM is here

使用标准<dependencies>标记在此POM中设置所有依赖项。模块POM将继承它们。 (更新:请参阅下面的评论,绝对值得探索<dependencyManagement>标记,而不是父POM。)

最后,每个模块POM都应该返回主POM。这样,如果您在其中一个模块目录中运行mvn(即您只是构建一个模块),它将查找父项的依赖项。您使用<parent>标记执行此操作,该标记将保留主POM的<groupid><artifactid><parent>标记的一个很好的示例,以及对多模块项目的良好总体审核is here