Соглашения об именовании Maven для иерархических проектов с несколькими модулями

У меня есть вопрос по соглашениям об именах Maven (groupId, artifactId и имена каталогов) в многокомпонентном проекте с иерархической структурой каталогов.

Исследовательская работа

Прежде чем спросить, я просмотрел другие веб-сайты на эту тему и то, что я прояснил для себя:

Возможно дублирование для моего вопроса, но оно не охватывает уровни с множественной иерархией.

Имя каталога проекта должно соответствовать artificatId.

Руководство по соглашениям об именах привести примеры:

идентификатор_группы будет идентифицировать ваш проект уникально во всех проектах, поэтому нам нужно применить схему именования. Он должен следовать правилам имени пакета (например, org.apache.maven, org.apache.commons, org.apache.maven.plugins)

артефакта Если вы создали его, вы можете выбрать любое имя с строчными буквами и без странных символов. (например, Maven, Commons-Math)

Это довольно просто, и я это понимаю, но есть несколько вещей, которые до сих пор неясны.

артефакта примеры, упомянутые в соглашениях, могут применяться только к одноуровневому модулю иерархии.

Примеры

Я просмотрел репозитории maven и извлек несколько примеров:

весна в основном использует имена: spring-core, spring-context, spring-context-support. Все автономные модули имеют одноуровневую иерархию и префикс для повышения эффективности поиска. Проблем нет, так как иерархия не такая глубокая.

Apache CXF Называния довольно нетрадиционны для Apache. Артефакты - это автономные модули с 5 различными именами артефактов, например. CxF-инструменты-wsdlto-JAXB-привязки.

Существует множество артефактов (cxf-rt-databinding-jaxb, cxf-rt-databinding-aegis, cxf-rt-databinding-xmlbeans, cxf-rt-databinding-sdo), которые можно сгруппировать в несколько модульных проектов (cxf-rt -dataindings), но они не сделали, и поэтому имена стали спагетти.

В заключение,Плагины Maven это первый проект с несколькими модулями (после org.apache.maven), который имеет такие артефакты, как: maven-compiler-plugin, maven -forcer-plugin.

Примеров достаточно много и все следуют разнымконвенции именования artifactIds (следовательно, каталоги проекта).

результат

Используя лучшие примеры из примеров, рассмотрим уровни иерархии.

Одноуровневая иерархия именования будет (

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. Спасибо.

Ответы на вопрос(3)

Ваш ответ на вопрос