分层多模块项目的 Maven 命名约定

Question

我对具有分层目录结构的多模块项目中的 Maven 命名约定(groupId、artifactId 和目录名称)有疑问。

研究

在询问之前，我浏览了有关此主题的其他网络以及我为自己清除的内容:

Possible duplication for my question, but it does not cover multiple-hierarchy levels.

Project directory name should match artificatId .

Guide to Naming Conventions
提供例子:

群组 ID 将在所有项目中唯一标识您的项目，因此我们需要强制执行命名模式。它必须遵循包名规则(例如 org.apache.maven、org.apache.commons、org.apache.maven.plugins)

Artifact ID 如果你创建了它，那么你可以选择任何你想要的名字，小写字母，没有奇怪的符号。
(例如 maven、commons-math)

这很简单，我理解它，但是仍然有一些不清楚的地方。

Artifact ID 约定中提到的示例只能应用于一级层次结构模块。

例子

我浏览了 maven 存储库并提取了一些示例:

Spring主要使用名称:spring-core、spring-context、spring-context-support。所有独立模块都是一级层次结构和 spring- 前缀以提高搜索效率。没有问题，因为层次结构没有那么深。

Apache CXF命名对于 Apache 来说是非常规的。 Artifact 是独立的模块，名称中最多有 5 个可能的不同 Artifact ，例如。 cxf-tools-wsdlto-databinding-jaxb。

有很多 Artifact (cxf-rt-databinding-jaxb、cxf-rt-databinding-aegis、cxf-rt-databinding-xmlbeans、cxf-rt-databinding-sdo)可以分组到多个模块项目中(cxf-rt -databindings)，但他们没有，所以名字变成了意大利面条。

最后，Maven Plugins首先是一个多模块项目(在 org.apache.maven 之后)，其中包含以下 Artifact :maven-compiler-plugin、maven-enforcer-plugin。

有很多示例，并且都遵循命名 artifactIds 的不同约定(因此是项目目录)。

结果

从示例中获取最佳实践让我们回顾层次结构级别。

一级层次结构命名将是(

groupId:    org.organization.project
artifactId: project-portal ---.
                              |
                              project-portal-service
                              |
                              project-portal-plugins (continued on next diagram)
                              |
                              project-portal-util

(续)两级层次结构将是:

groupId:    org.organization.project.plugins
artifactId: project-portal-plugins ---.
                                      |
                                      project-sample-plugin
                                      |
                                      project-another-great-plugin
                                      |
                                      ???? (multiple module project)

你看到问号了吗？那就是

问题

我遵循示例中的约定(忽略意大利面条 Apache CXF 示例):

根 - 项目门户(例如 spring-core、maven-core)

第一级层次结构名称继承自根 - project-portal-plugins(例如 spring-context-support)。

二级层次结构名称 - project-sample-plugin(例如 maven-compiler-plugin)。

现在我们被困在第三层，就像在没有保存和检查点的旧游戏中一样。

这是从 Maven 示例中获取的更深层次结构级别的正确目录命名路径吗？

您是否遵循任何约定或规则来支持简单的目录和 Artifact 名称，避免在更深层次上使用意大利面条名称？

如果有简单的名称，groupId 是否会从存储库中的冲突中保存重复的 Artifact 名称(由于简单而会发生)？

如何在具有重复名称的 Web/存储库上搜索和查找 Artifact (由于简单性)？

我不想在我的项目结构中看到像 project-portal-liferay-plugins-themes 这样的模块用于父级，或者更糟糕的是 project-portal-liferay-plugins-themes-white-puppy-wtf-name 用于 child 。

如果您可以为任何提到的问题和可能的问题提供您的意见和实践，那不仅对我有很大帮助，而且对使用 maven 的每个人也有很大帮助。谢谢你。

Answer 1

在早期使用 Maven 时，我遵循了您所描述的以下结构:

appname
  +--- appname-module1
  +--- appname-module2
              +--- appname-module2-chhild1
              +--- appname-module2-chhild2
  +--- appname-module3

但是，如果您获得更多级别，这将变得荒谬。

所以我决定改变主意，现在使用以下方法:

appname
  +--- module1
  +--- module2
          +--- chhild1
                 +--- subchild1
          +--- chhild2
  +--- module3

我通过关卡唯一改变的是 groupId ...

appname (groupId: com.soebes.appname)
  +--- module1 (groupId: com.soebes.appname.module1)
  +--- module2 (groupId: com.soebes.appname.module2)
          +--- chhild1 (groupId: com.soebes.appname.module1.child1)
          +--- chhild2 (groupId: com.soebes.appname.module1.child2)
  +--- module3 (groupId: com.soebes.appname.module3)