У меня есть вопрос по соглашениям об именах Maven (groupId, artifactId и имена каталогов) в проекте с несколькими модулями с иерархической структурой каталогов.
Прежде чем спросить, я просмотрел эту тему в Интернете и выяснил для себя:
Возможное дублирование моего вопроса, но оно не охватывает уровни множественной иерархии.
Руководство по соглашениям об именах приведите примеры:
groupId идентифицирует ваш проект уникальным образом во всех проектах, поэтому нам необходимо принудительно применить схему именования. Он должен соответствовать правилам имени пакета (например, org.apache.maven, org.apache.commons, org.apache.maven.plugins)
artifactId Если вы его создали, вы можете выбрать любое имя, которое хотите строчными буквами и без странных символов. (например, maven, commons-math)
Это довольно просто, и я понимаю это, но есть несколько вещей, которые все еще неясны.
artifactId Примеры, упомянутые в соглашениях, могут применяться только к модулю одноуровневой иерархии.
Я просмотрел репозитории maven и извлек несколько примеров:
Spring в основном использует имена: spring-core, spring-context, spring-context-support. Все автономные модули имеют одноуровневую иерархию и пружинный префикс для повышения эффективности поиска. Проблем нет, потому что иерархия не такая уж и глубокая.
Наименования Apache CXF довольно нетрадиционны для Apache. Артефакты - это отдельные модули с до 5 возможных различных артефактов в именах, например. cxf-tools-wsdlto-привязка данных-jaxb.
Существует множество артефактов (cxf-rt-databinding-jaxb, cxf-rt-databinding-aegis, cxf-rt-databinding-xmlbeans, cxf-rt-databinding-sdo), которые можно сгруппировать в проект с несколькими модулями ( cxf-rt-databindings), но они этого не сделали, и поэтому имена превратились в спагетти.
Наконец, Maven Plugins - это первый проект с несколькими модулями (после org.apache.maven), который имеет такие артефакты, как maven-compiler-plugin, maven-enforcer-plugin.
Существует довольно много примеров, и все они следуют различным соглашениям об именах идентификаторов артефактов (следовательно, каталогов проектов).
Взяв передовой опыт из примеров, давайте рассмотрим уровни иерархии.
Именование одноуровневой иерархии будет (
groupId: org.organization.project
artifactId: project-portal ---.
|
project-portal-service
|
project-portal-plugins (continued on next diagram)
|
project-portal-util
(продолжение) двухуровневой иерархией будет:
groupId: org.organization.project.plugins
artifactId: project-portal-plugins ---.
|
project-sample-plugin
|
project-another-great-plugin
|
???? (multiple module project)
Вы видите вопросительные знаки? Вот где
Я следовал условным обозначениям из примеров (игнорируя спагетти) Пример Apache CXF):
И вот мы застряли на третьем уровне, как в старых играх, без сохранений и чекпоинтов.
Я не хочу видеть в своей структуре проекта модуль вроде project-portal-liferay-plugins-themes для родительского или, что еще хуже, проект-портал-liferay-plugins-themes-white-puppy-wtf-name для детей.
Если бы вы могли поделиться своим мнением и практикой по любому из упомянутых вопросов и возможных проблем, это было бы большим подспорьем не только для меня, но и для всех, кто использует maven. Спасибо.