【问题标题】:Best practices for inheritance structure of a Maven Project with modules具有模块的 Maven 项目的继承结构的最佳实践
【发布时间】:2021-05-17 09:54:41
【问题描述】:

我正在尝试找出为以模块组织的 Maven 项目定义继承结构的最佳方法。
让我介绍一下场景。

我正在开发一个可以针对不同客户进行扩展的 Web 应用程序。
每个个性化都包含自定义 GUI 组件、数据仓库逻辑等。

我创建了主 pom.xml,定义为 packaging,它表示主项目容器并包括共享依赖项和模块定义:

  • 核心库模块:artifactID:cms-core
  • 基础 Web 应用程序 GUI 模块 artifcatId:cms-base-app
  • 客户 1 Web 应用程序模块
  • ...
  • 客户 N Web 应用程序模块

Pom.xml 定义如下:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>it.isipc</groupId>
  <artifactId>cms-env</artifactId>
  <version>0.0.0</version>
  <packaging>pom</packaging>
  <name>cms.env</name>
  <description>...</description>
  <properties>
    <maven.compiler.target>1.8</maven.compiler.target>
    <maven.compiler.source>1.8</maven.compiler.source>
  </properties>
  <build>
    ...
  </build>
  <dependencies>
        ...
  </dependencies>
  
  <modules>
    <module>cms-core</module>
    <module>cms-base-app</module>
    ...
    <module>cms-customer1</module>
    ...
  </modules>
</project>

基本上,我通常在 Core Library 和 Base 应用程序模块上进行更改。
每次我在这些模块中的任何一个上发布新版本时,我都需要更新每个客户模块的 pom.xml,以便在提到的工件的最后发布版本中更新它们。

以下是客户 Web 应用程序 **pom.xml** 的示例:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>it.isipc</groupId>
    <artifactId>cms-env</artifactId>
    <version>0.0.0</version>
  </parent>
  <version>1.11.05</version>
  <artifactId>cms-customer1</artifactId>
  <packaging>war</packaging>
  <name>cms-customer1/name>
  <description>...</description>
  <dependencies>
    <dependency>
        <groupId>it.isipc</groupId>
        <artifactId>cms-base-app</artifactId>
        <type>war</type>
        <version>1.11.05</version>
    </dependency>
    <dependency>
        <groupId>it.isipc</groupId>
        <artifactId>cms-core</artifactId>
        <version>1.1.3</version>
    </dependency>
  </dependencies>
</project>

目前我必须指定:

  1. 客户模块的版本(上例中为 1.11.05)
  2. cms-base-app 模块的版本(上例中为 1.11.05)

在我看来,这两个工件必须共享相同的版本号,因为客户应用程序扩展了基础 Web 应用程序。

一切正常,但我确信有最好的方法来做到这一点。

有一种方法可以仅在 cms-base-app pom.xml 文件中指定版本号并让每个客户的模块都继承自该文件吗?

感谢您的建议。

【问题讨论】:

  • 在你给出的例子中,有很多版本:cms-env:0.0.0cms-base-app:1.11.05cms-core:1.1.3cms-customer1:1.11.05。我认为所有“根”模块(env、core、base-app)都应该具有相同的版本。但是每个客户模块都应该能够以自己的方式发展(新功能、错误修复……)。即使customer“扩展”cms-env,它也可以有自己的版本。那么,你认为“根”模块一个版本,每个客户模块一个版本是可以的,还是你更喜欢一个版本?
  • 嗨@Tigger 感谢您的回答。我同意:每个客户模块都有自己的发展方式。我认为“根”模块的一个版本和每个客户模块的一个版本可能是最好的解决方案。我面临的主要问题是,每次更新“根”模块之一时,我都必须手动更新每个客户模块中的引用。我正在尝试找到一种简单/自动的方法来做到这一点
  • 首先你为什么要使用战争作为依赖?第二个最好的方法是在父级中为一般依赖项设置dependencyManagement。第三,为什么不同的模块有不同的版本?多模块旨在为所有模块提供相同的版本...
  • @khmarbaise 我将战争用作依赖项,因为我包含了未部署在 Maven 存储库上的旧脚本(当然我可以改进这种管理,只是需要更多时间)。我已经在“cms-env”pom.xml 中的“根”模块中管理了一般依赖项(我在示例中省略了它们)。在您看来,如果我更改客户组件/逻辑的版本,我应该更改所有模块的版本吗?我不认为这是一个更好的解决方案......我想只有通用依赖项和公共库必须共享版本号。

标签: java maven


【解决方案1】:

如果需要,这是一种可能的配置:

  • 所有“根”模块的一个版本
  • 每个“客户”模块一个版本

1。根模块

cms 环境

<groupId>it.isipc</groupId>
<artifactId>cms-env</artifactId>
<version>0.0.0</version>
<packaging>pom</packaging>
<modules>
    <module>cms-core</module>
    <module>cms-base-app</module>
    <module>cms-customer1</module>
</modules>

cms-核心

<artifactId>cms-core</artifactId>
<parent>
    <groupId>it.isipc</groupId>
    <artifactId>cms-env</artifactId>
    <version>0.0.0</version>
</parent>

cms-base-app

<artifactId>cms-base-app</artifactId>
<parent>
    <groupId>it.isipc</groupId>
    <artifactId>cms-env</artifactId>
    <version>0.0.0</version>
</parent>
<dependencies>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>cms-core</artifactId>
        <version>${project.version}</version>
    </dependency>
</dependencies>

在子 pom(corebase-app)中,无需指定 groupId 或版本,它是继承的。

2。客户模块

<artifactId>cms-customer1</artifactId>
<version>1.2.3</version>
<parent>
    <groupId>it.isipc</groupId>
    <artifactId>cms-env</artifactId>
    <version>0.0.0</version>
</parent>
<dependencies>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>cms-base-app</artifactId>
        <version>${parent.version}</version>
    </dependency>
</dependencies>

如果cms-base-app 依赖于cms-core(如第 1 部分中所设置),则无需在此处添加它,在客户模块中。

3。生命周期

customer1 进化时,只需编辑它的 pom(更改版本)。
当“根”模块发生变化时,所有的 pom 都必须更新。 为此,请转到cms-env 目录,然后:
mvn versions:set -DnewVersion=0.0.1
如果一切正常,您可以通过以下方式验证更改:
mvn versions:commit
否则,您可以通过以下方式返回之前的 pom:
mvn versions:rollback

【讨论】:

  • 感谢您的建议。我需要一些时间来测试它。过几天回复你
  • 我尝试了您的解决方案,它有效。基本上,“cms-core”和“cms-base-app”共享主项目版本号,每个客户实施都遵循自己的版本控制方式。也许,能够控制每个核心工件版本可能会更好,但是在这种环境下,两个核心工件都存在于主项目中。共享相同的版本号是一个很小的代价。我将您的回答标记为已接受的回答。谢谢您的帮助,干杯。
猜你喜欢
  • 2012-07-25
  • 2017-02-18
  • 2012-05-04
  • 1970-01-01
  • 2018-05-10
  • 2014-06-26
  • 2010-10-04
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多