Именование артефактов Maven и groupId

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

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

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

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

наконец, я должен забрать artifactId, Я в настоящее время пошел на teatimer. Но когда я смотрю на другие проекты Maven, они используют дефисы для разделения слов в artifactIds, Вот так: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.имя_компании.проект