我在Maven命名约定（groupId，artifactId和目录名称）在具有分层目录结构的多个模块项目中遇到了问题。
研究
在提问之前，我在网上搜寻了此主题并弄清楚了以下内容：
命名约定指南提供了示例：
groupId 将为所有项目唯一标识您的项目，因此我们需要强制使用命名架构。 它必须遵循包名称规则（例如 org.apache.maven，org.apache.commons，org.apache.maven.plugins）
artifactId 如果您创建了它，那么您可以选择任何小写字母且没有奇怪符号的名称。 (例如maven，commons-math)
这很简单直接，我也理解了，但还有一些事情不太清楚。
artifactId中提到的示例仅适用于一级层次结构模块。
例子
我已经浏览了Maven存储库并提取了一些示例：
Spring 大多使用名称：spring-core、spring-context、spring-context-support。 所有独立模块都是一级层次，并且spring-前缀可用于搜索效率。 由于层次不太深，所以没有问题。
Apache CXF 命名对于Apache来说相当非传统。 Artifacts 是具有高达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插件是第一个多模块项目（在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示例）：
- 根目录 - project-portal（例如spring-core，maven-core）
- 一级层次名称从根继承 - project-portal-plugins（例如spring-context-support）。
- 二级层次名称 - project-sample-plugin（例如maven-compiler-plugin）。
现在我们卡在第三层上，就像没有保存和检查点的老游戏一样。
- 这是源于Maven示例的正确目录命名路径吗，用于更深层次的层级结构？
- 是否有任何惯例或规则可遵循，以支持简单的目录和构件名称，避免在较深层次上出现混乱的名称？
- 如果有简单的名称，groupId是否会从仓库中的碰撞中保存重复的构件名称（由于简单性而发生）？
- 关于寻找和发现具有重复名称的构件的问题（由于简单性而导致）怎么办？
我不希望在我的项目结构中看到一个模块，比如project-portal-liferay-plugins-themes，甚至是更糟糕的project-portal-liferay-plugins-themes-white-puppy-wtf-name这样的子级。
如果您能就任何提到的问题和可能出现的问题提供您的意见和做法，那将不仅对我有所帮助，也将对使用Maven的每个人都有所帮助。谢谢。
groupId:artifactId、文件夹结构和项目<name>同步，这样当我进行反应堆构建时，我可以清楚地看到正在构建什么并保留层次结构的视图（因为反应堆不一定按顺序构建）。另一件事是，在大型项目中，您可能会有多个具有相同artifactId的子项目（但具有不同的groupId），这有助于避免混淆 - 当然代价是显而易见的 :) - haylem