У меня вопрос о соглашениях об именах 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 -context-support. Все автономные модули представляют собой одноуровневую иерархию и spring - префикс для эффективности поиска. Нет проблем, поскольку иерархия не так глубока.

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-databindings), но они этого не сделали, и поэтому имена стали спагетти.

Наконец, Maven Plugins - это проект с несколькими модулями (после org.apache.maven), который имеет артефакты вроде: maven-compiler- плагин, плагин maven-enforcer.

Существует довольно много примеров, и все они следуют различным соглашениям об именах 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 спагетти):

• Корень - проект-портал (например, spring -core, maven-core)
• Иерархические имена первого уровня наследуют от root-project-portal-плагинов (например, spring -context-support).
• Иерархические имена второго уровня - project-sample-plugin (например, maven-compiler-plugin).

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

• Это правильный путь именования каталогов, взятый из примеров Maven для более глубоких уровней иерархии?
• Существуют ли какие-либо соглашения или правила для поддержки простых имен каталогов и артефактов, избегая имен спагетти на более глубоких уровнях?
• Если есть простые имена, будет groupId сохранять дублированные имена артефактов (что произойдет из-за простоты) из коллизий в репозитории?
• Как насчет поиска и поиска артефактов в Интернете/репозиториях с дублируемыми именами (из-за простоты)?

Я не хочу видеть в моей структуре проекта модуль, такой как project-portal-liferay-plugins-themes для родительского или даже худшего проекта-портала-liferay-plugins-themes-white-puppy-wtf-name для детей.

Если бы вы могли предоставить свое мнение и практику по любым из упомянутых вопросов и возможных проблем, это было бы большой помощью не только для меня, но и для всех, кто использовал maven. Спасибо.