Maven артефакт и присвоение имен группам

291

В настоящее время я нахожусь в процессе переноса какого-то проекта из Ant в Maven. Конформист, как и я, я хочу использовать общепринятые соглашения для поиска groupIdи artifactId, но я не могу найти какие-либо подробные соглашения (есть некоторые, но они не охватывают вопросы, которые меня интересуют).

Возьмите этот проект, например, сначала пакет Java: com.mycompany.teatimer

Таймер чая на самом деле состоит из двух слов, но соглашения об именах пакетов Java запрещают вставку символов подчеркивания или дефиса, поэтому я пишу все это вместе.

Я выбрал groupIdидентичный идентификатору пакета, потому что думаю, что это хорошая идея. Это?

Наконец, я должен выбрать artifactId, я в настоящее время пошел на teatimer. Но когда я смотрю на других проектах Maven, они используют дефис для разделения слов в artifactIdсек, как это: tea-timer. Но это выглядит странно , когда присоединялись к groupId: com.mycompany.teatimer.tea-timer.

Как бы вы это сделали?

Другой пример:

Имя пакета: com.mycompany.awesomeinhouseframework

groupId: com.mycompany.awesomeinhouseframework(?)

artifactId: awesome-inhouse-framework(?)

maven-2 naming-conventions

— Noarth
источник

1

Где вы видите groupId, соединенный с artifactId? Я думаю, что соглашения, которые вы заявляете, являются правильными.

— Абхинав Саркар

2

На самом деле, подчеркивания допускаются в именах пакетов java, см. Docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

— Адриан Костер,

146

Ваше соглашение кажется разумным. Если бы я искал ваш фреймворк в репозитории Maven, я бы искал awesome-inhouse-framework-x.y.jarв com.mycompany.awesomeinhouseframeworkкаталоге группы. И я нашел бы это там согласно вашему соглашению.

У меня работают два простых правила:

обратные доменные пакеты для groupId (поскольку они довольно уникальны) со всеми ограничениями, касающимися имен пакетов Java
имя проекта как artifactId (помните, что оно должно быть удобным для имени jar, то есть не содержать символов, которые могут быть недопустимы для имени файла или выглядят странно)

— Хенрик Консек
источник

Хорошо, если вы и abhin4v считаете это нормальным, тогда я сделаю это просто так, спасибо!

— Noarth

Я нахожу смесь слов без дефиса (awesomeinhouseframework) и дефиса (awesome-inhouse-framework) правописанием несколько странной. Так как groupid не допускает дефисы, я бы придерживался написания не дефиса и для артефакта.

— Майкл Кюллер

3

Пожалуйста, уточните, что вы имеете в виду под "jar-name friendly"?

— vikramvi

1

Уточнил в ответ :).

— Henryk Konsek

241

Странность очень субъективна, я просто предлагаю следовать официальной рекомендации:

Руководство по соглашениям об именах для groupId, artifactId и version

groupIdбудет идентифицировать ваш проект уникально во всех проектах, поэтому нам нужно применить схему именования. Он должен следовать правилам имени пакета, что означает, что оно должно быть как минимум доменным именем, которым вы управляете, и вы можете создать столько подгрупп, сколько захотите. Посмотрите на Больше информации об именах пакетов .

например. org.apache.maven,org.apache.commons

Хороший способ определить гранулярность groupId - использовать структуру проекта. То есть, если текущий проект является проектом с несколькими модулями, он должен добавить новый идентификатор к groupId родителя.

например. org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting

artifactIdэто имя банки без версии. Если вы создали его, вы можете выбрать любое имя с строчными буквами и без странных символов. Если это баночка стороннего производителя, вы должны взять название банки по мере ее распространения.

например. maven,commons-math

versionесли вы распространяете его, вы можете выбрать любую типичную версию с номерами и точками (1.0, 1.1, 1.0.1, ...). Не используйте даты, поскольку они обычно связаны со сборками SNAPSHOT (ночные). Если это сторонний артефакт, вы должны использовать его номер версии, какой бы он ни был, и как бы странно это ни выглядело.

например. 2.0, 2.0.1,1.3.1

— Паскаль Тивент
источник

4

Я знаю эти соглашения, но они на самом деле не говорят, как должно быть составлено имя артефакта (нет соглашений об именах JAR) и что делать, если оно будет таким же, как groupId - я не видел ни одного POM где это так.

— Noarth

@Noarth 1. Имя артефакта на ваше усмотрение (но использование дефисов в имени - обычная практика). 2. Вы ищете абсолютное «правило», которого не существует (что если ваша удивительная внутренняя структура состоит из нескольких модулей?). См., Например, артефакты Spring, Maven, Hibernate и т. Д.

— Паскаль Thivent

Нет, нет, у меня нет никаких модулей, только простые проекты. На самом деле, у нас нет проекта под названием «потрясающая внутренняя структура» :)

— Noarth

11

Как насчет package? Какая разница для groupId?

— KonstantinK

1

Разрешено ли в artifactId иметь числа?

— theonlygusti

100

Рассмотрим следующее для создания базового первого приложения Maven :

groupId

com.companyname.project

artifactId

проект

version

0.0.1

— Manwal
источник

Как работу по найму я должен использовать com.my.company.projectкак groupIdили com.client.company.project?

— Джакомо Альзетта

@GiacomoAlzetta вы можете использовать любой формат подходит вам лучше. Некоторые примеры «com.companyName.hirePortal» или «org.compnayName.hirePortal».

— Манвал

3

groupId должен быть com.companyname, а не com.companyname.project

— Камил Неканович

1

Однако я не согласен с официальным определением Руководства по соглашениям об именах для groupId, artifactId и версии, в котором предлагается, чтобы groupId должен начинаться с обратного доменного имени, которым вы управляете.

comозначает, что этот проект принадлежит компании, и orgозначает, что этот проект принадлежит социальной организации. Это нормально, но для таких странных доменов, как xxx.tv, xxx.uk, xxx.cn, не имеет смысла называть groupId, начинающийся с "tv.", "Cn.", GroupId должен предоставлять основную информацию проекта, а не домена.

— Tommy.Tang
источник

2

Это соглашение запрещает разработчикам использовать maven из-за того, что вы должны владеть доменом, прежде чем развертывать свои артефакты в центральном хранилище maven. Это нелепо. Владение доменом может быть довольно дорого с каждым годом.

— Tommy.Tang

1

Там нет не требования фактически владельца регистрации для этого доменного имени. Единственное требование заключается в том, чтобы идентификатор вашей группы, который будет именем вашего пакета Java, не конфликтовал с любым другим таким именем при развертывании. Это соглашение, безусловно, не мешает разработчикам использовать Maven.

— Василий Бурк

Хорошей практикой является получение имен пакетов из URL-адреса хранилища. Если вы используете GitHub, ваша учетная запись называется myuserи ваш репозиторий называется myrepo, тогда просто используйте имя пакета com.github.myuser.myrepo. Это бесплатно и все еще уникально.

— fxnn

-14

Учтите это, чтобы получить полностью уникальный файл JAR:

GroupID - com.companyname.project
ArtifactId - com-название компании-проект
Пакет - com.companyname.project

— кодировщик
источник