Имена в java, maven и gradle

Центральным аспектом философии Java является то, что имена имеют значение.

Центральным аспектом философии Java является то, что имена имеют значение.

Пакеты

Если вы работаете на “acme.com ” и вы работаете над проектом под названием “foo”, тогда соглашение заключается в том, что ваш корневой пакет должен быть com.acme.foo .

Быть дальновидной группой , мы склонны добавлять много пакетов “группировки”. Наш проект food – это служебная библиотека, и мы могли бы создать другие, поэтому мы поместили ее в com.acme.util.foo , чтобы убедиться, что есть место для других служебных проектов. Если мы действительно смотрим в будущее, мы примем во внимание, что foo – это служебная библиотека для работы с текстом, поэтому нам лучше поместить ее в com.acme.util.text.foo . С другой стороны, ЯГНИК .

В мире javascript нет пакетов, вы просто получаете одно имя – foo – и все. Я рад, что большую часть своей работы я выполняю на JVM, а не на среде выполнения, которая была разработана и собрана за 10 дней , но всякий раз, когда я начинаю вкладывать свой корневой пакет глубже, чем com.acme.foo , я пытаюсь вспомнить, что все эти куски программного обеспечения, написанные в Node.js обходятся вообще без вложенности, так что, возможно, я смогу обойтись 3 или 4 уровнями вложенности для моего корневого пакета, а не 5 или 6.

Maven groupId: артефактИд

Одна приятная особенность файлов .class заключается в том, что вам не нужно выбирать для них имена – они автоматически получают свое имя из сопоставления 1: 1 в файле .java , из которого они были получены. К сожалению, maven просит вас выбрать два имени, так что это не может быть так просто. К счастью, maven также предоставляет не только один , но и два немного отличающихся соглашения о том, как выбирать эти имена! Соответственно, если вы спросите StackOverflow , вы увидите два популярных ответа. И когда такая крупная библиотека, как RxJava, выпустит новую версию, вам понадобится обсуждение длиной в 12 экранов , чтобы выяснить, какими должны быть имена.

К счастью, существует механистический ответ! Jetpack превращает любой коммит git в артефакт maven в https://jitpack.io , который, как я обнаружил, является огромным улучшением по сравнению с -SNAPSHOT для интеграционного тестирования. Соглашение об именовании, которое он использует, является:

• com.github.{пользователь}:{репозиторий} (также com.gitlab , org.bitbucket и com.gitee )
• com.github.{user}.{repo}:{subproject} для многомодульных сборок.

Если вы используете интеграцию Jetpack custom domain , то вы можете заменить com.github.{user} на com.acme для профессионального подхода. Даже если вы не используете Jetpack, использование этого соглашения будет означать, что вы могли бы , и оно устанавливает простое правило, которое достаточно хорошо работает для всех этих людей .

Идентификатор плагина Gradle

В Gradle-land вы можете применить плагин следующим образом: plugins { id 'any.plugin.id.you.want' } . Gradle обеспечивает отличное руководство :

В качестве соглашения мы рекомендуем вам использовать идентификатор, основанный на шаблоне обратного домена, используемом для пакетов Java, например org.example.greeting.

Проблема в том, что огромное количество плагинов, которые были опубликованы до сих пор, имеют имена… gradle-плагин . Это кажется разумным, пока вы пишете плагин, и вы не понимаете, насколько это глупо, пока вы не используете это издалека:

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

Что это за машина? Это автомобиль “Шевроле Корветт”. Что это за телефон? Это iPhone XS Iphone. Разве это не было бы лучше?

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

Это интересно, потому что рекомендации, которые дает Gradle, очень хороши – никакой чрезмерной вложенности, никаких ненужных gradle.gradle , только самый минимум. И все же, многие люди, которые используют мне кажется, что они должны добавить gradle или два, на всякий случай. Вероятно, единственным способом спасти нас от самих себя было бы, если бы инструмент gradle выполнял поиск gradle в идентификаторе и выдавал предупреждение, чтобы помочь нам немного подумать об этом перед публикацией.

Занятия

Проектирование пространств имен – редкая возможность. Большинство из нас никогда не делают этого ни разу за всю свою карьеру. И поскольку ни у кого нет опыта в этом, мы все еще совершаем много ошибок новичков, даже в мире java, которому уже четверть века. Это тяжело! Опечатки, Атаки на омограф IDN , есть так много подводных камней. Если я когда-нибудь закончу определением пространства имен, я постараюсь запомнить эти уроки:

• пространства имен полезны для идентификации автора/сопровождающего: com.acme.foo 👍
• пространства имен являются излишними для мелкозернистых категорий: com.acme.util.text.foo 👎
• определение имени как кортежа из двух других имен – это 👎
• если все имена являются плагинами для foo bar , люди просто назовут их my-foobar-plugin , и было бы неплохо предупредить их, что это, вероятно, не лучший выбор \ _ (ツ) _/

Оригинал: “https://dev.to/nedtwigg/names-in-java-maven-and-gradle-2fm2”