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

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

Исследование

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

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

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

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

    • 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):

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

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

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

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

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

33
задан Community 23 May 2017 в 12:09
поделиться