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

JMe*_*nik 33 directory-structure naming-conventions hierarchy maven multi-module

我在一个带有分层目录结构的多模块项目中有一个关于Maven命名约定(groupId,artifactId和目录名称)的问题.

研究

在询问之前,我通过其他网络了解了这个主题以及我为自己清理的内容:

  1. 我的问题可能重复,但它不包括多层次级别.

  2. 项目目录名称应与artificatId匹配.

  3. 命名约定指南 提供了示例:

    • 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.所有独立模块都是一级层次结构和弹出前缀,以提高搜索效率.没有问题,因为等级不是那么深.

Apache CXF命名对于Apache来说是非常规的.工件是独立模块,在名称中最多可包含5个不同的工件.CXF的工具,wsdlto,数据绑定,JAXB.

有很多工件(cxf-rt-databinding-jaxb,cxf-rt-databinding-aegis,cxf-rt-databinding-xmlbeans,cxf-rt-databinding-sdo),它们可以分组在多个模块项目中(cxf-rt) - 数据绑定),但他们没有,因此名称成为意大利面条.

最后,Maven插件首先是一个多模块项目(在org.apache.maven之后),它有一些工件,如: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
Run Code Online (Sandbox Code Playgroud)

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

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

你看到问号?多数民众赞成在哪里

问题

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

  • 根 - 项目门户(例如,spring-core,maven-core)
  • 第一级层次结构名称从root - project-portal-plugins继承(例如,spring-context-support).
  • 二级层次结构名称 - project-sample-plugin(例如maven-compiler-plugin).

现在我们被困在第三级,就像没有保存和检查点的旧游戏一样.

  1. 这是从更深层次结构级别的Maven示例中获取的正确目录命名路径吗?
  2. 您是否遵循任何约定或规则来支持简单的目录和工件名称,以避免更深层次上的意大利面条名称?
  3. 如果有简单的名称,groupId会从存储库中的冲突中保存重复的工件名称(这将由于简单性而发生)吗?
  4. 如何在具有重复名称的Web /存储库上搜索和查找工件(由于简单性)?

我不希望在我的项目结构中看到一个像project-portal-liferay-plugins-themes这样的模块用于父级,甚至更糟糕的是project-portal-liferay-plugins-themes-white-puppy-wtf-name for children.

如果你能提出你提出的任何问题和可能出现的问题的意见和做法,这不仅对我,而且对每个使用maven的人都有很大的帮助.谢谢.

khm*_*ise 20

在maven的早期,我遵循了您描述的以下结构:

appname
  +--- appname-module1
  +--- appname-module2
              +--- appname-module2-chhild1
              +--- appname-module2-chhild2
  +--- appname-module3
Run Code Online (Sandbox Code Playgroud)

但如果你获得更多关卡,这将变得荒谬.

所以我决定改变主意,现在使用以下内容:

appname
  +--- module1
  +--- module2
          +--- chhild1
                 +--- subchild1
          +--- chhild2
  +--- module3
Run Code Online (Sandbox Code Playgroud)

我通过关卡改变的唯一一件事就是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)
Run Code Online (Sandbox Code Playgroud)


wem*_*emu 5

在这种情况下,我认为没有任何约定可以明确指定您应该如何设置项目结构。

例如,我会尝试回答这些工件的名称在哪里,以及遇到冲突的可能性有多大。对于像 spring 这样的框架,在 artifactId(“spring-*”)中包含项目名称确实有意义,对于 commons- 库也是如此(尽管“commons-logging”可能是一个危险的名称)。

对于独立运行的项目,我可能没有必要这样做。但看起来您将使用 Liferay 门户,其中会有很多不同的罐子,所以我鼓励为工件添加前缀。但我不会尝试基于 artifactId 重建项目结构。所以“project-modulename”将是一个很好的模块名称。由于 jar 将构建类路径,并且在构建期间定义了依赖结构,因此这不是问题。如果您需要根据 jar 列表重建依赖关系树:maven 在 META-INF 中包含信息(如果您使用我也推荐的 release-plugin),因此可以从那里检索信息。

我还建议不要将模块嵌套得太深。Eclipse 对此有一些问题(IntelliJ 没有,Netbeans afaik 也支持嵌套结构)。

与插件模块相比,主门户模块可能不会经常更改。所以我把它们分成单独的项目是有意义的——这也允许单独发布项目。

对我来说,用“-parent”后缀命名父模块是一个很好的做法。这些模块很少用作依赖项,依赖项的“-parent”表示某些东西是可疑的。正如您所说:artifacId 和模块名称应该相同。我还建议在 pom.xml 中使用 artifactId 作为名称。一些插件不考虑这里的差异,如果这些值都相同,Eclipse 也会表现得更好。

goupId 和 artifactId 确实经常包含重复的信息(例如,它的一部分将是项目名称)。如果这是故意这样做的,或者发生在过去几年......?我不知道,但我会保持这种方式。使用 GAV(P) 坐标(groupId、artifactId、version、(packaging))识别工件。如果 groupId 或 artifactId 包含 projectname 工件,如果您只有其中之一,则更容易找到工件。

如果您正在运行存储库管理器(如 Nexus、Artifactory、Archiva),则查找工件很容易。搜索通常会呈现 groupId/artifactId 等,因此搜索“util”将为您提供足够的信息来找到您正在寻找的工件。

希望这有点帮助:) 问候

威姆