分层多模块项目的Maven命名约定 [英] Maven naming conventions for hierarchical multiple module projects

问题描述

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

I've got a question on Maven naming conventions (groupId, artifactId and directory names) in a multiple module project with a hierarchical directory structrure.

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

Before asking, I went through other the web on this topic and what I cleared out for myself:

1. 我的问题可能重复，但它不涉及多层次结构级别.

项目目录名称应匹配 artificatId .

Project directory name should match artificatId.

命名约定指南 提供示例:

• groupId 将在所有项目中唯一地标识您的项目，因此我们需要实施命名架构.它必须遵循程序包名称规则(例如org.apache.maven，org.apache.commons，org.apache.maven.plugins)

• 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 如果创建了它，则可以选择任何需要的名称，包括小写字母和没有奇怪的符号. (例如maven，commons-math)

artifactId If you created it then you can choose whatever name you want with lowercase letters and no strange symbols. (eg. maven, commons-math)

这很简单，我理解，但是还有一些不清楚的地方.

This is quite straightforward and I understand it, but there are few things that are still unclear.

artifactId 示例只能应用于一级层次结构模块.

artifactId examples mentioned in conventions can be applied only to one-level hierarchy module.

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

I went through maven repositories and extracted some examples:

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

Spring mostly uses names: spring-core, spring-context, spring-context-support. All standalone modules are one-level hierarchy and spring- prefix for search efficiency. There are no problems, since hierarchy is not that deep.

Apache CXF 的命名对于Apache而言是非常不常规的.工件是独立模块，名称中最多包含5种可能的不同工件. cxf-tools-wsdlto-databinding-jaxb.

Apache CXF namings are quite unconventional for Apache. Artifacts are standalone modules with up to 5 possible different artifacts in names eg. cxf-tools-wsdlto-databinding-jaxb.

有很多工件(cxf-rt-databinding-jaxb，cxf-rt-databinding-aegis，cxf-rt-databinding-xmlbeans，cxf-rt-databinding-sdo)可以组合在多个模块项目中( cxf-rt-databindings)，但它们没有，因此名称变成了意大利面条.

There are lots of artifacts (cxf-rt-databinding-jaxb, cxf-rt-databinding-aegis, cxf-rt-databinding-xmlbeans, cxf-rt-databinding-sdo) which could be grouped in multiple module project (cxf-rt-databindings), but they didn't and so the names became spaghetti.

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

Finally, Maven Plugins is first a multiple module project (after org.apache.maven) which has artifacts like: maven-compiler-plugin, maven-enforcer-plugin.

有很多示例，所有示例均在命名artifactId(因此为项目目录)时遵循不同的惯例.

There are quite a lot of examples and the all follow different conventions on naming artifactIds (consequently project directories).

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

Taking best practices from the examples let us review hierarchy levels.

一级层次结构命名为(

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

(续)两级层次结构为:

(continued) two-level hierarchy would be:

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

您看到问号了吗?那就是

You see question marks? Thats where the

我遵循了示例中的约定(忽略了意粉Apache CXF示例):

I followed conventions from examples (ignoring spaghetti Apache CXF example):

• 根-项目门户(例如spring-core，maven-core)
• 第一层层次结构名称是从根-项目门户插件(例如spring-context-support)继承的.
• 二级层次结构名称-project-sample-plugin(例如maven-compiler-plugin).

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

And now we are stuck on third-level, like in old games without saves and checkpoints.

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

我不想在我的项目结构中看到像父母一样的项目portal-liferay-plugins-themes主题模块，或者对于孩子来说更糟的project-portal-liferay-plugins-themes-white-puppy-wtf-name模块.

I don't want to see in my project structure a module like project-portal-liferay-plugins-themes for parent or even worse project-portal-liferay-plugins-themes-white-puppy-wtf-name for children.

如果您可以针对任何提到的问题和可能的问题提供您的意见和实践，那么这不仅对我而且对使用maven的每个人都将有很大帮助.谢谢.

If you could provide your opinion and practice for any of mentioned questions and possible problems, that would be a great help not only for me, but and for everyone using maven. Thank you.

推荐答案

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

In earlier days with maven I followed the following structure which you have described:

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

但是，如果您获得更多的关卡，这将变得荒谬.

But this will become ridiculous if you get more levels.

所以我决定改变主意，现在使用类似的东西:

So I decided to change my mind and now using things like:

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

我唯一更改的级别是groupId ...

The only thing which I change through the levels is the 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)

这篇关于分层多模块项目的Maven命名约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！