时间戳

首页 > 解决方案 > 使用大量工件组织 Maven 项目的方法

java - 使用大量工件组织 Maven 项目的方法

问题描述

我正在尝试组织我的 Maven 项目。

假设我的项目被称为“真棒”。“真棒”有几个工件，每个工件都以不同的方式构建（例如，其中一些可能是用一些插件构建的，另一些是用一些其他插件构建的）：通常这些构建配置是有限且有限的（假设有大多数构建工件的 3 种不同方式），但是，每个工件只能使用一个构建构建（例如，utility工件是以maven-jar-plugin特定方式配置构建的，而工件client-ui是maven-war-plugin通过特定方式配置构建的）。

现在，我知道我可以按如下方式组织 Maven 项目：

awesome-root
 |---jars
 |    |--- utility
 |    |--- client-model
 |    |--- task-model
 |    |--- supplier-model
 |    |--- client-logic
 |    |--- task-logic
 |    ---- supplier-logic
 |---wars
      |--- client-ui
      |--- task-ui
      ---- supplier-ui

这样，每个特定的配置构建都可以放在build --> plugins项目的部分中jars，wars而通用属性/依赖管理/插件管理可以放在awesome-root.

问题： 我很快意识到开发人员生成的工件彼此密切相关，但构建不同。在前面的示例中，我们可以注意到可以以其他方式对工件进行分组：

awesome-root
 |--- tasks
 |     |--- task-model
 |     |--- task-logic
 |     ---- task-ui
 |--- clients
 |     |--- client-model
 |     |--- client-logic
 |     ---- client-ui
 |--- supplier
 |     |--- supplier-model
 |     |--- supplier-logic
 |     ---- supplier-ui
 |--- others
       |--- utility

这种分组的主要优点是tasks和clients是suppliers3 个不同的独立软件部门。当开发人员需要对client扇区进行更改时，她在文件系统的一小部分（或 IDE 中的项目资源管理器选项卡中，如 Eclipse）中拥有所需的一切。反之亦然，在第一个映射中，clients软件部门在项目存储库中被打乱了。

虽然这可能没什么大不了的，但如果“真棒”项目开始变得非常大，有很多工件等等，查找clients扇区的所有相关部分开始很烦人（并非不可能，IDE 提供了用于此目的的搜索）。我会说第二种结构要好得多，开发人员明智。

然而，在 maven 中实现这个策略似乎很困难：主要困难是为每个工件放置不同的构建配置（例如，*-ui需要以不同的方式构建*-model）。

我的问题是：

附加信息：

感谢您的回复

标签： javamaven

解决方案

推荐阅读