分层多模块项目的Maven命名约定
在一个具有分层目录结构的多模块项目中，我有一个关于Maven命名约定(groupId、artifactId和目录名称)的问题。
研究
在询问之前，我浏览了关于这个主题的其他网站，以及我为自己清除了哪些内容：
- 我的问题可能重复，但不包括多层次。
- 项目目录名应与artificatId匹配。
- 命名公约指南提供了一些例子：
- **groupId** will identify your project uniquely across all projects, so we need to enforce a naming schema. It has to follow the package name rules (eg. org.apache.maven, org.apache.commons, org.apache.maven.plugins)
- **artifactId** If you created it then you can choose whatever name you want with lowercase letters and no strange symbols. (eg. maven, commons-math)
这是非常直截了当的，我理解，但很少有事情还不清楚。
约定中提到的artifactId示例只能应用于一级层次结构模块。
示例
我浏览了maven存储库并提取了一些示例：
春天主要使用名称:spring核心、spring上下文、spring上下文支持。所有独立模块都是一层层次结构和弹簧前缀，以提高搜索效率.没有问题，因为等级没有那么深。
Apache名称对于Apache来说是非常非常规的。工件是独立的模块，有多达5种可能的不同工件的名称，例如。工具-wsdlto-databinding-jaxb
有很多工件(cxf-rt-databinding-jaxb，cxf-rt-databinding-aegis，cxf-rt-databinding-xmlbean，cxf-rt-databinding-sdo)，它们可以分组在多个模块项目(cxf-rt-databindings)中，但它们没有，因此名称变成了意大利面。
最后，Maven插件首先是一个多模块项目(仅次于org.apache.maven)，它具有类似于:maven-编译器-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示例)：
- 根-项目-门户(如。弹簧芯，maven-核)
- 一级层次结构名称继承自根项目门户插件(例如。春季-上下文-支持)
- 二级层次结构名称-项目-示例-插件(例如。maven编译器插件)。
现在我们被困在第三层，就像在没有扑救和检查点的老游戏中一样。
- 这是从Maven示例中获取的正确目录命名路径吗？
- 您是否遵循任何惯例或规则来支持简单目录和工件名称，避免在更深层次上使用意大利面名称？
- 如果有简单的名称，groupId会从存储库中的冲突中保存重复的工件名称(由于简单而产生的)吗？
- 如何在web/存储库中搜索和查找具有重复名称的工件(由于简单性原因)？
我不想在我的项目结构中看到一个模块，比如项目-门户-救生圈-插件-主题的父母，甚至更糟的的孩子。
如果您能够提供您的意见和实践中提到的任何问题和可能的问题，这将是一个伟大的帮助，不仅对我，而且对每个使用maven的人。谢谢。
回答 3
Stack Overflow用户
发布于 2012-02-27 07:49:43
在早期的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)Stack Overflow用户
发布于 2012-02-27 07:26:12
在这种情况下，我不认为有什么约定可以明确说明如何设置您的项目结构。
我会试着回答这些文物是以它们的名字结束的，并且有发生冲突的可能性。对于像spring这样的框架来说，在artifactId中使用项目名称("spring-*")确实是有意义的，对于公共库来说也是如此(尽管“commons”可能使用一个危险的名称)。
对于一个独立运行的项目，我可能没有必要这样做。但是看起来您将使用一个救生筏门户，在那里会有很多不同的罐子，所以我会鼓励为工件设置一个前缀。但是我不会尝试基于artifactId重新构建项目结构，所以“project”将是一个很好的模块名。由于jars将构建类路径，并且依赖关系结构是在构建过程中定义的，所以这不是一个问题。如果您需要基于jars列表重新构建依赖树: maven在META中包含信息(如果您使用我也推荐的release)，那么可以从其中检索信息。
我还建议不要将模块嵌套得很深。Eclipse在这方面存在一些问题(IntelliJ不支持，Netbeans也支持嵌套结构)。
与插件模块相比，主门户模块可能不会改变。因此，我有理由将它们分割成单独的项目--这也将允许将项目分开发布。
对我来说，用"-parent“后缀命名父模块是一种很好的做法。这些模块很少用作依赖项，依赖项的"-parent“表示可疑的东西。正如您所说: artifacId和模块名称应该是相同的。我还建议在pom中使用artifactId作为名称。有些插件不考虑这里的差异，而且如果这些值都相同的话，Eclipse的行为也会更好。
的确，goupId和artifactId通常包含重复的信息(例如，它的部分将是项目名称)。如果这件事是故意的还是发生在过去几年.？我不知道，但我会保持这种状态。工件使用GAV(P)坐标(groupId、artifactId、version、packaging)进行标识。如果groupId或artifactId包含项目名称，那么如果只有其中一个，则更容易找到它们。
如果您正在运行存储库管理器(比如Nexus、Artifactory、Archiva)，那么查找工件是很容易的。搜索通常会呈现groupId/artifactId等等，因此对"util“的搜索将为您提供足够的信息来查找您正在寻找的工件。
希望这有一点帮助:)问候
韦母
Stack Overflow用户
发布于 2012-03-10 11:45:34
另一种可能的方法是更多地查看函数组而不是层次结构。
假设项目B有webapp应用程序、插件和核心librairies，那么所有模块共享同一个组id (com.mycompany.b)，人工制品分别命名为webapp-？核心-？
我们还使用前面提到的-parent约定:因此，所有webapp的父POM称为webapp-parent.pom。
https://stackoverflow.com/questions/9435460
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号