Maven groupId 和artifactId 命名
我目前正在将一些项目从 Ant 迁移到 Maven。由于我是墨守成规的人，我想使用既定的约定来查找 groupId 和 artifactId，但我找不到任何详细的约定（有一些，但它们没有没有涵盖我想知道的要点）。
以这个项目为例，首先是Java包：com.mycompany.teatimer
Tea timer实际上是两个单词，但是Java包命名约定禁止插入下划线或连字符，所以我把它们写在一起。
我选择与包 ID 相同的 groupId 因为我认为这是一个好主意。是吗？
最后，我必须选择一个 artifactId，我目前选择了 teatimer。但是当我查看其他 Maven 项目时，他们使用连字符来分割 artifactId 中的单词，如下所示：tea-timer。但当连接到groupId时，它看起来确实很奇怪：com.mycompany.teatimer.tea-timer。
你会怎么做？
另一个例子：
包名称：com.mycompany.awesomeinhouseframework
groupId：com.mycompany.awesomeinhouseframework (?)
artifactId ：很棒的内部框架（？）
I'm currently in the process of moving some project from Ant to Maven. Conformist as I am, I want to use well-established conventions for finding groupId and artifactId, but I can't find any detailed conventions (there are some, but they don't cover the points I'm wondering about).
Take this project for instance, first the Java package: com.mycompany.teatimer
Tea timer is actually two words, but the Java package naming conventions forbid the insertion of underscores or hyphens, so I'm writing it all together.
I chose the groupId identical to the package ID because I think that's a good idea. Is it?
Finally, I have to pick an artifactId, I currently went for teatimer. But when I look at other Maven projects, they use hyphens to split words in artifactIds, like this: tea-timer. But it does look weird when concatenated to the groupId: com.mycompany.teatimer.tea-timer.
How would you do this?
Another example:
Package name: com.mycompany.awesomeinhouseframework
groupId: com.mycompany.awesomeinhouseframework (?)
artifactId: awesome-inhouse-framework (?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
奇怪是非常主观的，我只是建议遵循官方建议：
Weirdness is highly subjective, I just suggest to follow the official recommendation:
你的约定似乎是合理的。如果我在 Maven 存储库中搜索您的框架，我会在
com.mycompany.awesomeinhouseframework组目录中查找awesome-inhouse-framework-xyjar。我会按照你们的约定在那里找到它。两个简单的规则对我有用：
groupId的反向域包（因为它们非常独特）以及所有 约束将 Java 包名称artifactId（请记住，它应该是 jar 名称友好的，即不包含可能对文件名无效或看起来很奇怪的字符）Your convention seems to be reasonable. If I were searching for your framework in the Maven repo, I would look for
awesome-inhouse-framework-x.y.jarincom.mycompany.awesomeinhouseframeworkgroup directory. And I would find it there according to your convention.Two simple rules work for me:
groupId(since such are quite unique) with all the constrains regarding Java packages namesartifactId(keeping in mind that it should be jar-name friendly i.e. not contain characters that maybe invalid for a file name or just look weird)请考虑以下内容来构建基本的第一个 Maven 应用程序：
groupIdcom.companynameartifactIdproject<代码>版本
Consider the following for building a basic first Maven application:
groupIdcom.companynameartifactIdprojectversion但是，我不同意 groupId、artifactId 命名约定指南的官方定义，以及建议 groupId 必须以您控制的反向域名开头的版本。
com表示该项目属于公司，org表示该项目属于社会组织。这些都可以，但是对于像xxx.tv、xxx.uk、xxx.cn这样奇怪的域名，以“tv.”、“cn.”开头的groupId命名是没有意义的，groupId应该传递基本信息项目的而不是域的。However, I disagree the official definition of Guide to naming conventions on groupId, artifactId, and version which proposes the groupId must start with a reversed domain name you control.
commeans this project belongs to a company, andorgmeans this project belongs to a social organization. These are alright, but for those strange domain like xxx.tv, xxx.uk, xxx.cn, it does not make sense to name the groupId started with "tv.","cn.", the groupId should deliver the basic information of the project rather than the domain.除了其他之外，我还建议避免将团队名称作为组 ID 的一部分。根据我的经验，项目通常可以在团队之间移动，或者团队可以重命名，因此这不利于识别工件。
In addition to others, I can recommend avoiding team names as part of group ids. From my experience, projects can often move between teams or a team can be renamed, so that's not good for identifying artifacts.