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

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

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

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

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

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

Ответы

Ответ 1

В предыдущие дни с maven я выполнил следующую структуру, которую вы описали:

appname
  +--- appname-module1
  +--- appname-module2
              +--- appname-module2-chhild1
              +--- appname-module2-chhild2
  +--- appname-module3

Но это станет смешно, если вы получите больше уровней.

Поэтому я решил передумать и теперь использовал такие вещи, как:

appname
  +--- module1
  +--- module2
          +--- chhild1
                 +--- subchild1
          +--- chhild2
  +--- module3

Единственное, что я могу изменить через уровни, это groupId...

appname (groupId: com.soebes.appname)
  +--- module1 (groupId: com.soebes.appname.module1)
  +--- module2 (groupId: com.soebes.appname.module2)
          +--- chhild1 (groupId: com.soebes.appname.module1.child1)
          +--- chhild2 (groupId: com.soebes.appname.module1.child2)
  +--- module3 (groupId: com.soebes.appname.module3)

Ответ 2

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

например. Я попытался бы ответить, где артефакты заканчиваются своим именем и какова вероятность столкновения с конфликтом. Для такой структуры, как spring, имеет смысл иметь имя проекта в artifactId ( "spring - *" ), то же самое верно для commons-библиотек (хотя "commons-logging" может быть рискованным именем).

Для проекта, который работает автономно, я, вероятно, не нужен для этого. Но похоже, что вы будете использовать портал liferay, где будет много разных банок, поэтому я бы рекомендовал префикс для артефактов. Но я бы не стал пытаться перестроить структуру проекта на основе artifactId. Таким образом, "project-modulename" будет хорошим именем модуля. Поскольку банки будут строить путь к классам, а структура зависимостей была определена во время сборки, это не проблема. Если вам нужно перестроить дерево зависимостей на основе списка jars: maven включает информацию в META-INF (если вы используете плагин release, который я также рекомендую), чтобы получить информацию оттуда.

Я бы также рекомендовал не глубоко встраивать модули. У Eclipse есть некоторые проблемы с этим (IntelliJ не делает, Netbeans afaik поддерживает вложенные структуры тоже).

Основной модуль портала не может меняться так часто по сравнению с модулями плагина. Поэтому я имею в виду разделить их на отдельные проекты - это также позволит разделить проекты отдельно.

Для меня это хорошая практика, чтобы назвать родительские модули суффиксом "-parent". Эти модули редко используются в качестве зависимости, а "-parent" для зависимости указывает, что что-то подозрительно. Как вы сказали: artifacId и имя модуля должны быть одинаковыми. Я также рекомендовал бы использовать artifactId как имя в pom. Некоторые плагины не рассматривают различия здесь, а также Eclipse ведет себя лучше, если эти значения одинаковы.

Правда, goupId и artifactId часто содержат дублируемую информацию (например, ее части будут именем проекта). Если это было сделано специально или произошло в последние годы...? Я не знаю, но я буду держать это таким образом. Артефакты идентифицируются с использованием координат GAV (P) (groupId, artifactId, версия, (упаковка)). Если groupId или artifactId содержат артефакты projectname, их легче найти, если у вас есть только один из них.

Поиск артефактов легко, если вы используете диспетчер репозитория (например, Nexus, Artifactory, Archiva). Поиск часто отображает groupId/artifactId и т.д., Поэтому поиск "util" даст вам достаточно информации, чтобы найти артефакт, который вы ищете.

надеюсь, это немного помогло:) рассматривает

wemu

Ответ 3

Другим возможным подходом является просмотр функциональных групп больше, чем иерархия.

Предположим, что в проекте B есть webapps, плагины и основные librairies, тогда все модули имеют один и тот же идентификатор группы (com.mycompany.b), а артефакты соответственно называются webapp -???, plugin -??? и ядро ​​-.

Мы также используем соглашение -parent, упомянутое ранее: поэтому родительский POM для всех webapps называется webapp-parent.pom.