Именование артефактов Maven и groupId
в настоящее время я в процессе перемещения некоторого проекта из Ant в Maven. Конформист, как я, я хочу использовать устоявшиеся соглашения для поиска groupId
и artifactId
, но я не могу найти никаких подробных соглашений (есть некоторые, но они не охватывают моменты, о которых мне интересно).
возьмите этот проект, например, сначала пакет Java:com.mycompany.teatimer
чай таймер на самом деле два слова, но Соглашения об именах пакетов Java запрещают вставка подчеркиваний или дефисов, поэтому я пишу все это вместе.
я выбрал groupId
идентичный идентификатор пакета, потому что я думаю, что это хорошая идея. Это?
наконец, я должен забрать artifactId
, Я в настоящее время пошел на teatimer
. Но когда я смотрю на другие проекты Maven, они используют дефисы для разделения слов в artifactId
s, Вот так:tea-timer
. Но это выглядит странно, когда сцеплено с groupId
: com.mycompany.teatimer.tea-timer
.
как бы вы сделали это?
еще пример:
название пакета: com.mycompany.awesomeinhouseframework
groupId
: com.mycompany.awesomeinhouseframework
(?)
artifactId
: awesome-inhouse-framework
(?)
4 ответов
ваша конвенция кажется разумной. Если бы я искал вашу структуру в репозитории Maven, я бы искал awesome-inhouse-framework-x.y.jar
на com.mycompany.awesomeinhouseframework
каталог группы. И я найду его там согласно вашей конвенции.
для меня работают два простых правила:
- reverse-domain-пакеты для groupId (так как они довольно уникальны) со всеми ограничения относительно имен пакетов Java
- название проекта как artifactId (имея в виду, что это должно быть jar-name дружественным, т. е. не содержать символов, которые могут быть недействительными для имени файла или просто выглядеть странно)
странность очень субъективна, я просто предлагаю следовать официальной рекомендации:
руководство по соглашениям об именах groupId, artifactId и version
groupId
определит ваш проект уникально во всех проектах, поэтому нужно применить схему именования. Он должен следовать за именем пакета правила, что значит, что должно быть на как минимум, как доменное имя, которое вы контролируете, А вы можно создать столько подгрупп как вы хотите. более подробная информация о названиях пакетов.например.
org.apache.maven
,org.apache.commons
хороший способ определить гранулярность groupId-использовать структура проекта. То есть, если текущий проект представляет собой несколько модулей проект, он должен добавить новый идентификатор groupId родителя.
например.
org.apache.maven
,org.apache.maven.plugins
,org.apache.maven.reporting
artifactId
- имя jar без версии. Если вы его создали тогда вы можете выбрать любое имя, которое вы хотите с строчными буквами и нет странный символ. Если это третья сторона jar вы должны взять имя jar, как он распространяется.например.
maven
,commons-math
version
если вы распространяете его, то вы можете выбрать любой типичный версия с цифрами и точками (1.0, 1.1, 1.0.1, ...). Не используйте даты, как они обычно связаны с SNAPSHOT (nightly) строит. Если это артефакт третьей стороны, вы должны использовать их номер версии, что бы это ни было, и как бы странно это ни выглядело.например.
2.0
,2.0.1
,1.3.1
рассмотрите следующее как для построения basic first Maven применение:
groupId
- com.имя_компании.проект
artifactId
- проект
version
- 0.0.1
рассмотрим это, чтобы получить полностью уникальный файл jar:
- GroupID-com.имя_компании.проект
- ArtifactId-com-companyname-project
- пакет-com.имя_компании.проект