应用maven groupId命名约定 [英] Applying maven groupId naming convention

问题描述

我正在开发一些项目（目前组织为eclipse项目）。有一个核心项目，主要提供核心API和一些辅助实现和抽象类。所有其他项目都依赖于这个项目。

I am developing a number of projects (currently organized as eclipse projects). There is a core project which mainly provides the core API and some secondary implementations and abstract classes. All other projects depend on this project.

当将项目集成到我们的maven存储库时，我们遇到了maven命名约定的问题。正如在SO上讨论的那样，groupId通常应该是反向公司域名（ com.example ）加上项目名称（ com.example.foo ）。 maven命名约定为子项目提供了额外的后缀，例如插件（ com.example.foo.plugin ）。

When integrating the projects into our maven repository, we got problems with the maven naming conventions. As discussed on SO, the groupId should usually be the reverse company domain name (com.example) plus the project name (com.example.foo). The maven naming conventions suggest an additional postfix for sub-projects such as plugins (com.example.foo.plugin).

在我们的例子中，我们没有插件，而是核心项目提供的API的多个（大多数是独立的）实现。我们当前的命名建议是：

In our case, we have not got plugins, but multiple (mostly independent) implementations of the API provided by the core project. Our current naming suggestion is:

• com.example.foo as groupId of所有项目，虽然它们被分成不同的java包（ com.example.foo 包含API， com.example.foo.bar 包含 bar 实现）


• 项目名称为artifactId，没有引用项目的前缀（ bar 而不是 foo-bar ）

• com.example.foo as the groupId of all projects, although they are split up into different java packages (com.example.foo contains the API, com.example.foo.bar contains the bar implementation)
• the project name as the artifactId, without a prefix referring to the project (bar instead of foo-bar)

关键点在于（虽然我们的项目如上所述在各个包中展开）但它们实际上并不是API核心项目的子项目。

The key point is that (although our projects are spread accross packages as described above) they are not really sub-projects of the API core project.

这个建议是否符合maven命名约定？

Does this suggestion comply with the maven naming conventions?

以防万一：这个问题是不要求提出意见回复，但要求提出一个有争议的答案上面的问题。

Just in case: This question is not asking for opiniated responses but for an argumentative answer to the above question.

推荐答案

我想说这是你自己的品味和偏好。

I would say this is a matter of your own taste and preference.

通常，您可以在相同的 groupId 下对类似的模块组进行分组。例如，您可以拥有以下内容：

Normally, you would group similar sets of modules under the same groupId. For example, you could have the following:

com.foo.bar:parent                          (parent pom for all projects)
com.foo.bar:core-api                        (some very core classes)
com.foo.bar:commons                         (some common classes)
com.foo.bar:io                              (some IO classes)
com.foo.bar:utils                           (some utility classes)
com.foo.bar.messaging:messaging-core        (messaging core classes)
com.foo.bar.messaging:messaging-rest-api    (REST API for messaging)
com.foo.bar.messaging:messaging-jms         (some JMS code)
com.foo.bar.web:rest-api                    (your restlets)
com.foo.bar.web:web-core                    (core classes to be used by web modules)
com.foo.bar.web:web-parent                  (a parent pom for all your web projects)
com.foo.bar.web:web-ui                      (UI stuff like css/images/js/etc)
com.foo.bar.web:web-assembly                (a web assembly that bundles all modules)
... (I hope by now you get my drift) ...

您不一定需要在类 groupId 下将所有类以一个公共包开头的模块分组。如果您愿意， 可以做到这一点，但很少人们真正在现实生活中如何使用它。严格程度和细节程度取决于您，但在工件的情况下，它通常无关紧要，因为没有什么可以将包名称绑定到 groupId 。

You don't necessarily need to group all modules whose classes start with a common package under the same groupId. You could do that, if you like, but that's rarely how people really use it in real life. The level of strictness and magnitude of detail is up to you, but in the case of artifacts, it usually doesn't matter that much as there's nothing to tie the package name to the groupId.

此外，为模块使用前缀也很有帮助，但由您决定。如果你愿意，你可以：

Furthermore, using a prefix for your modules is also helpful, but up to you. If you like, you could have:

com.foo.bar:bar-parent
com.foo.bar:bar-core-api
com.foo.bar:bar-commons

这是真的取决于你。有些人会争辩说，如果你有一个 groupId ，比如 com.foo.bar ，那你就不需要了 bar < - code>前缀 bar-parent 。在某种程度上，这是事实。但是你可以有 com.foo.bar:parent 和 com.foo.bar.web：parent 以及何时您正在使用Nexus，Archiva或Artifactory等存储库管理器，并且您正在搜索 parent ，（或其他一些常见名称，如... 例如，你可能会得到一个相当长的结果列表，而不是 bar-parent 。

This is really up to you. Some will argue that if you have a groupId like com.foo.bar, then you don't need to have a bar- prefix in bar-parent. To some extent this is true. But then you could have com.foo.bar:parent and com.foo.bar.web:parent and when you're using a repository manager like Nexus, Archiva or Artifactory and you're searching for parent, (or some other common name like... commons, for example), you might end up with a rather long list of results, as opposed to bar-parent.

最后，重要的是你愿意去哪些细节以及什么才能真正满足你的需求。 Maven为您提供了所需的所有自由。

In the end, what matters is to what level of detail you're willing to go and what will really suit your needs. Maven allows you all the freedom you need in this regard.

这篇关于应用maven groupId命名约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！