Java，Maven和Gradle中的名稱

Java哲學的中心方面是名稱很重要。Brian Goetz，Java語言架構師和Java Concurrency in Practice的作者

Packages

If you work for "acme.com" and you're working on a project called "foo" then the convention is for your root package to be

com.acme.foo

.

Being a forward-looking bunch, we tend to add lots of "grouping" packages. Our foo project is a utility library, and we might make other ones, so we put it into

com.acme.util.foo

, to make sure there is space for other utility projects. If we're really forward-looking, we'll take into account that foo is a utility library for manipulating text, so we better put it into

com.acme.util.text.foo

. On the other hand, YAGNI.

In the javascript world, there are no packages, you just get one name -

foo

- and that's it. I'm glad that I do most of my work on the JVM rather than a runtime which was designed and built in 10 days, but whenever I start nesting my root package deeper than

com.acme.foo

, I try to remember that all those gobs of software being written in Node.js are getting by without any nesting at all, so maybe I can get by with 3 or 4 levels of nesting for my root package, rather than 5 or 6.

Maven groupId:artifactId

One nice thing about

.class

files is that you don't have to pick names for them - they get their name automatically from a 1:1 mapping on the

.java

file they came from. Unfortunately, maven asks you to pick two names, so it can't be that simple. Luckily, maven also provides not only one, but two slightly different conventions for how to pick these names! Accordingly, if you ask StackØverflow, you'll see two popular answers. And when a major library like RxJava ships a new version, you'll need a 12-screen-long debate to figure out what the names ought to be.

幸運的是，那裡有一個機械的答案！ JitPack将任何git commit轉換為Maven工件https://jitpack.io，我發現它在-快照用于內建測試。 它使用的命名約定是：

• com.github。{user}：{repo}（也com.gitlab，org.bitbucket， and com.gitee）com.github。{user}。{repo}：{subproject}用于多子產品建構。

If you use JitPack's custom domain integration, then you can replace

com.github.{user}

with

com.acme

for a professional touch. Even if you don't use JitPack, using this convention will mean that you could, and it lays down a simple rule that works well enough for all these people.

Gradle plugin id

In Gradle-land, you can apply a plugin like this:

plugins { id 'any.plugin.id.you.want' }

. Gradle provides an excellent guideline:

按照慣例，我們建議您使用基于Java包的反向域模式的ID，例如org.example.greeting。

The trouble is, a huge number of the plugins which have been published so far are named...

gradle-plugin

. It seems reasonable while you're writing the plugin, and you don't realize how silly it is until you use it from a distance:

plugins {
    id 'com.acme.gradle.foo'
    id 'org.nonprofit.bar.bar-gradle-plugin'
    id 'beetlejuice.beetlejuice.gradle'
}
           

那是什麼車？ 那就是雪佛蘭克爾維特汽車。 那是什麼電話？ 這是一部iPhone XS手機。 這會更好嗎？

plugins {
    id 'com.acme.foo'
    id 'org.nonprofit.bar'
    id 'beetlejuice'
}
           

很有意思，因為Gradle給出的指導非常好-沒有過多的嵌套，沒有不必要的嵌套搖動.搖動，隻是最低要求。 然而，很多人使用感覺他們應該添加一個搖動 or two, just in case. Probably the only way to save us from ourselves would be for the 搖動 tooling to search for 搖動在ID中提出警告，以幫助我們在釋出之前進行一些思考。

Lessons

Designing namespaces is a rare opportunity. Most of us never do it even once in our entire career. And since nobody has experience in it, we're still making lots of beginner mistakes, even in the quarter-century-old world of java. It's hard! Typosquatting, IdN homograph attacks, there are so many pitfalls. If I ever end up defining a namespace, I'm gonna try to remember these lessons:

• 命名空間有助于識别作者/維護者：com.acme.foo👍對于細粒度的類别，名稱空間是過大的：com.acme.util.text.foo👎defining the name to be a tuple of two other names is👎如果名稱全部是foob​​ar，人們隻會給他們起名字my-foob​​ar-plugin，并且警告他們可能不是最好的選擇\\（（））_ /

from: https://dev.to//nedtwigg/names-in-java-maven-and-gradle-2fm2