0%

2020.1.7

先吐槽一下百度,输入 java包命名规则 搜到的都是一堆垃圾文章。
有时间可以自己去试试,看看搜到的东西和 Oracle 官方写的文档差了多远……


今天想要花点时间去建设自己的服务器(五彩方块),我准备给它写一些新的插件。
花了一点时间构思自己准备写的项目之后,我发现自己之前使用了四年之久的 HamsterAPI 逐渐跟不上自己的需求了。因为它太旧、太老、太难用了!
毕竟这个 API 是我四年前开发的,虽然中途一直修修补补凑合着使用,但总归还是保留了许多当年仓鼠不成熟时的痕迹。
现在,五彩方块服务器重建,全部插件都将要重新写过,那我为什么不把这套 API 也重写一番呢?
正好也能用这套即将开发出来的 API 检验一下现在的自己和四年之前相比到底有什么变化。

我琢磨了一下新的 API 应该如何命名,既然它要完全重现,那肯定不能是 HamsterAPI-2.0.0 之类的名称,因为这样原来的 HamsterAPI 就无法被加载了,如果我拿着新的 API 去给其他老板开发插件的话,那么老板装上新的 API 之后,旧 API 无法使用将会导致我给他编写的其他插件全部无法运行…

最后我决定使用 57BlockAPI 这个名称,代表了我的服务器自主研发的一套 API 系统。(因为这样子说给别人听的时候会让其他人感觉很厉害)

然后我还仔细去研究了一番 Maven 项目的命名规则:

groupId:定义当前Maven项目隶属的实际项目,例如org.sonatype.nexus,此id前半部分org.sonatype代表此项目隶属的组织或公司,后部分代表项目的名称,如果此项目多模块话开发的话就子模块可以分为org.sonatype.nexus.plugins和org.sonatype.nexus.utils等。特别注意的是groupId不应该对应项目隶属的组织或公司,也就是说groupId不能只有org.sonatype而没有nexus。

例如:我建立一个项目,此项目是此后所有项目的一个总的平台,那么groupId应该是org.jsoft.projectName,projectName是平台的名称,org.jsoft是代表我个人的组织,如果以我所在的浪潮集团来说的话就应该是com.inspur.syncdata。

artifactId:是构件ID,该元素定义实际项目中的一个Maven项目或者是子模块,如上面官方约定中所说,构建名称必须小写字母,没有其他的特殊字符,推荐使用“实际项目名称-模块名称”的方式定义,例如:spirng-mvn、spring-core等。

推荐格式:使用实际项目名称作为artifactId的前缀,紧接着为模块名称

举例:nexus-indexer、spring-mvc、hibernate-c3po……这些id都是以实际项目名称作为前缀,然后接着一个中划线,再紧跟项目的模块名称,默认情况下maven会在artifactId添加version作为最后生成的名称。例如:spirng-mvn-2.0.0.jar

version:版本号,不要使用日期作为版本,推荐例如这样的命名:2.0、2.0.1、1.3.1,如果为快照版本(SNAPSHOT),那么会自动在版本号后面加上快照的标识。

原地址:https://my.oschina.net/u/4412493/blog/4228129

好吧,这是我在百度上搜索 maven 命名规则 得到的一个比较令人满意的一个结果…

所以我给我的这个项目命名 groupIdnet.57block.bukkitartifactIdapi-core(也许还得做一些api-guiapi-command 之类的 Maven 项目?)

我总感觉有哪里不对劲,我总觉得上面写的这些有什么地方不对……

于是我又想去找找 Maven 官方提供的规范文档,在 Google 搜索框中键入 maven naming 之后,我找到了自己想要的几个页面:https://maven.apache.org/guides/mini/guide-naming-conventions.htmlhttps://stackoverflow.com/questions/3724415/maven-artifact-and-groupid-naming

官方文档中有几点引起了我的注意:

A group ID should follow Java’s package name rules.

翻译:一个 groupId 应该遵循 Java包命名规范
该文档为 Java SE 6 时的规范,也许有些老旧,我使用 Google 搜索找到了 Java SE 8 时的 Java 包命名规范文档,这两个文档内容上没有什么区别,但第二个链接的文档表述更清晰易懂。

一般开发人员都大致了解 Java 包命名规范,但其中有三点值得注意:

  • If the domain name contains a hyphen, or any other special character not allowed in an identifier (§3.8), convert it into an underscore.
  • If any of the resulting package name components are keywords (§3.9) then append underscore to them.
  • If any of the resulting package name components start with a digit, or any other character that is not allowed as an initial character of an identifier, have an underscore prefixed to the component.

翻译:

  • 如果你的包名中包含不允许出现的特殊字符,则将它转换为下划线。
  • 如果你的包名中出现了关键字等不允许的特殊字符,则在它后面添加下划线。(例如:com.example.int 转换为 com.example.int_
  • 如果你的包名以数字之类不允许的字符,则在它前面添加下换线。(例如:net.57block.bukkit 转换为 net._57block.bukkit

这样一来,我的 groupId 就得更改为 net._57block.bukkit 了。

但是 Maven 文档中还有另一点引起了我的注意:

Maven does not enforce this rule. There are many legacy projects that do not follow this convention and instead use single word group IDs. However, it will be difficult to get a new single word group ID approved for inclusion in the Maven Central repository.

翻译:Maven 并不强制你遵守这个规则。有许多历史遗留的项目都没有遵守该规则,而是使用单个单词作为 groupID。但是,使用单个单词作为 groupID 的新项目将很难被批准加入 Maven Central 仓库。

好吧,说白了就是 Maven 并不强制我去遵守他们的命名规定,但如果我按照他们的规定去命名,我的代码将有机会被载入 Maven 中央仓库。

可是我要他有何用啊…

所以我决定不遵守 artifactId 的命名规定,搞一堆 api-coreapi-guiapi-command 之类的工件太麻烦了,比起这些我更想要将自己的精力放在代码上。

说白了,Apache 也好 Oracle 也好,他们写出这些规定都只是为了尽量减少大家的麻烦,如果大家都能按照约定去命名,那么团队之间(或者项目之间)的合作就减少很多不必要的麻烦。
但如果这个规定本身就已经给我带来了麻烦,那么我也应该考虑一下是否可以不去遵守它。

再思考一下,Maven 许多约定都是为了 JavaWeb 开发而定的。但 bukkit 插件开发并不像 JavaWeb 一样有成熟的体系。Bukkit 和 Tomcat 也不是同一个东西…
我觉得我的项目如此命名并没有什么不妥,即使是其他开发者想要使用我的项目,net._57block.bukkit57BlockAPI 也并不是很难理解。

最后我决定就使用这个名称了。

人生不易,仓鼠断气