У меня есть вопрос по соглашениям об именах Maven (groupId, artifactId и имена каталогов) в многомодульном проекте с иерархической структурой каталогов.
Исследования
Перед тем как спросить, я пошелчерез другие веб-сайты на эту тему и то, что я прояснил для себя:
Возможное дублирование для моего вопроса, но оно не охватывает уровни множественной иерархии.
Имя каталога проекта должно соответствовать artificatId .
Руководство по соглашениям об именах Приведите примеры:
groupId будет уникально идентифицировать ваш проект во всех проектах, поэтому нам нужно применить схему именования.Он должен следовать правилам имени пакета (например, org.apache.maven, org.apache.commons, org.apache.maven.plugins)
artifactId Если вы создали его, вы можете выбрать любое имя с строчными буквами и без странных символов.(например, maven, commons-math)
Это довольно просто, и я понимаю это, но есть несколько вещей, которые все еще неясны.
artifactId примеры, упомянутые в соглашениях, могут применяться только к одноуровневому модулю иерархии.
Примеры
Я просмотрел репозитории maven и извлек несколько примеров:
Spring в основном использует имена: spring-core, spring-context, spring-контекстно-поддержка.Все автономные модули имеют одноуровневую иерархию и префикс для повышения эффективности поиска.Проблем нет, поскольку иерархия не такая глубокая.
Наименования Apache CXF для Apache весьма нетрадиционны.Артефакты - это автономные модули с 5 различными именами артефактов, например.CxF-инструменты-wsdlto-JAXB-привязки.
Существует множество артефактов (cxf-rt-databinding-aegis, cxf-rt-databinding-xmlbeans, cxf-rt-databinding-sdo), которые могут быть сгруппированы в несколькомодульный проект (cxf-rt-databindings), но они этого не сделали, и имена стали спагетти.
Наконец, Плагины Maven - это первый проект с несколькими модулями (после org.apache.maven), в котором есть такие артефакты, как: maven-compiler-plugin, maven-forcecer-plugin.
Существует довольно много примеров, и все они следуют различным соглашениям по именованию artifactIds (следовательно, projectкаталоги).
Результат
Используя лучшие примеры из примеров, рассмотрим уровни иерархии.
Одноуровневое именование иерархии будет (
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):
- Root - проект-портал (напр.spring-core, maven-core)
- Имена иерархии первого уровня наследуются от root - project-portal-plugins (например, spring-context-support).
- Имена иерархии второго уровня -project-sample-plugin (например, maven-compiler-plugin).
И теперь мы застряли на третьем уровне, как в старых играх без сохранений и контрольных точек.
- Это правильный путь именования каталогов, взятый из примеров Maven для более глубоких уровней иерархии?
- Существуют ли какие-либо соглашения или правила, которым вы следуете, чтобы поддерживать простые имена каталогов и артефактов, избегая имен спагетти на более глубоких уровнях?
- Если есть простые имена, будет ли groupId сохранять дублированные имена артефактов (что произойдет из-за простоты) из коллизий в репозитории?
- Как насчет поиска и поиска артефактов в сети / репозиториях с дублированными именами (из-за простоты))?
Я не хочу видеть в своей структуре проекта такой модуль, как project-portal-liferay-plugins-themes для родителей или, что еще хуже, project-portal-liferay-plugins-themes-white-puppy-wtf-name для детей.
Если бы вы могли высказать свое мнение и попрактиковаться в решении любого из упомянутых вопросов и возможных проблем, это было бы большой помощью не только для меня, но и для всех, кто использует maven.Спасибо.