Maven совет относительно управления версиями большого проекта и избегания версий, содержащих выражения - PullRequest
5 голосов
/ 20 января 2012

Я смотрю на реструктуризацию большого проекта Maven ...

Базовый обзор нашей текущей структуры:

build [MVN plugins, third party dependency management]:5.1
   NRW Utils:6.0.0.0-beta12-SNAPSHOT
      server-utils:6.0.0.0-beta12-SNAPSHOT
      ... 
   CMW Root:6.0.0.0-beta12-SNAPSHOT
      cmw-webapp:6.0.0.0-beta12-SNAPSHOT
      cmw-core [dependencies on NRW Utils]:6.0.0.0-beta12-SNAPSHOT
      ...
   NRW Root :6.0.0.0-beta12-SNAPSHOT
      nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-beta12-SNAPSHOT
      ...

Причина изменения:

Размер каждого коллективного модуля (то есть NRW Utils, CMW Root и NRW Root) увеличивается, и процесс сборки начинает занимать невыносимое время (иногда ~ 4 часа).

Новый план:

build [MVN plugins, third party dependency management]:5.1
   NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT
      server-utils:6.0.0.0-NU-beta4-SNAPSHOT
      ... 
   CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT
      cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT
      cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT
      ...
   NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT
      nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT
      ...  

Мы начали вводить «ключи» в версии, чтобы различать разные «коллективные модули» и, следовательно, легко выполнять пошаговые выпуски. Кроме того, наши служебные модули гораздо более стабильны, поэтому нам может потребоваться не так много бета-версий - теперь нет ограничений на синхронизацию бета-чисел.

Стоит также отметить, что на самом деле существует 5 разных «коллективных модулей» (а не только 3), которые должны быть собраны с разными версиями (отличающимися уникальными ключами), поэтому я подумал, что было бы неплохо иметь централизованное место для версий, в отличие от дублирующих свойств в 5 разных POM.

Проблема теперь заключается в содержимом файлов POM при определении зависимостей от модулей в другом «коллективном модуле» другой версии.

Предлагаемое решение для управления версиями зависимостей:

build [MVN plugins, third party dependency management]:5.1
   nrw-version-management:6.0.0.0-beta-SNAPSHOT
      [contains properties defining latest versions of each collective module]   
      NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT
         server-utils:6.0.0.0-NU-beta4-SNAPSHOT
         ... 
      CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT
         ...
      NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT
         nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT
         ... 

nrw-version-management (pom.xml):

...
<parent>
    <groupId>com.project</groupId>
    <artifactId>build</artifactId>
    <version>5.1</version>
</parent>
<groupId>com.project</groupId>
<artifactId>nrw-versions-manager</artifactId>
<version>6.0.0.0-beta-SNAPSHOT</version>
<name>Version Maven Properties</name>
<description>A centralised place for all module property versions</description>
<packaging>pom</packaging>
<properties>
    <nrw.utilities.version>6.0.0.0-NU-beta4-SNAPSHOT</nrw.utilities.version>
    <nrw.cmw.version>6.0.0.0-CMW-beta12-SNAPSHOT</nrw.cmw.version>
    <nrw.version>6.0.0.0-NRW-beta9-SNAPSHOT</nrw.version>
</properties>
...

CMW Root (pom.xml):

...
<parent>
    <groupId>com.project</groupId>
    <artifactId>nrw-versions-manager</artifactId>
    <version>${nrw.core.version}</version>
    ...
</parent>
<groupId>com.project</groupId>
<artifactId>CMW-root</artifactId>
<version>6.0.0.0-CMW-beta12-SNAPSHOT</version>
<packaging>pom</packaging>
<dependencyManagement>
    <dependencies>
        ...
        <dependency>
            <groupId>${project.groupId}</groupId>
            <artifactId>server-utils</artifactId>
            <version>${nrw.utilities.version}</version>
        </dependency>
        ...
</dependencyManagement>
<profiles>
    <profile>
        <id>all</id>
        <modules>
            <module>cmw-webapp</module>
            <module>cmw-core</module>
            ...
        </modules>
    </profile>
    ...
</profiles>
...

N.B. тогда для свойства $ {nrw.core.version} будет установлено значение 6.3.0.0-beta-SNAPSHOT для создания снимка с помощью аргументов командной строки (или значения свойства по умолчанию).

Возможный процесс выпуска (для 6.0.0.0):

  1. Сборка модуля сборки 5.1, если он еще не собран
  2. Сборка nrw-version-management 6.0.0.0 (чтобы избежать зависимостей моментальных снимков - однако свойства пока не изменены)
  3. Сборка NRW Utils 6.0.0.0-NU cmd args: -Dnrw.core.version = 6.0.0.0
  4. Сборка CMW Root 6.0.0.0-CMW cmd args: -Dnrw.core.version = 6.0.0.0 -Dnrw.utilities.version = 6.0.0.0-NU
  5. Сборка NRW Root 6.0.0.0-NRW cmd args: -Dnrw.core.version = 6.0.0.0 -Dnrw.utilities.version = 6.0.0.0-NU -Dnrw.cmw.version = 6.0.0.0-CMW
  6. Перестройте nrw-version-management 6.0.0.0 для хранилища. cmd args: -Dnrw.core.version = 6.0.0.0 -Dnrw.utilities.version = 6.0.0.0-NU -Dnrw.cmw.version = 6.0.0.0-CMW
  7. Сборка nrw-version-management 6.1.0.0-beta-SNAPSHOT с новыми версиями для разработчиков и обновлением POM-файла

Проблема:

Процесс сборки выглядит запутанным, особенно в связи с модулем управления версиями nrw. Также я начал видеть это предупреждение:

'version' содержит выражение, но должно быть константой

И, проведя некоторое исследование, я теперь понимаю, что выражения не рекомендуется при установке версий (при указании родительского POM):

Вопросы:

  • Могу я просто проигнорировать это предупреждение? Некоторые публикации начинают предполагать, что может быть просто допустимо указывать родительские версии POM, используя свойства.
  • Является ли этот общий подход общепринятым? Или ущербный?
  • Существуют ли лучшие решения для реструктуризации этого растущего проекта?

Заранее спасибо.

Ответы [ 3 ]

2 голосов
/ 31 января 2012

Как сказал nico_ekito в одном из комментариев, по моему собственному мнению, вы сейчас попадаете в "кошмар управления зависимостями".Согласно вашему сценарию ... разве сам факт управления разными версиями для подмодулей (а также разной стабильностью кода) не является признаком того, что эти подмодули больше не являются частью большого проекта?

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

Так что, возможно, стоит разделить кодовые базы в разных структурах и просто ссылаться на утилитуфайлы из модулей, которые действительно требуют этого, и просто используют стабильные сборки вместо «последней версии этой зависимости».Если работа со стабильными сборками невозможна, потому что, хотя код для этих зависимостей довольно стабилен, он продолжает меняться в то же время, что и код из других модулей, но решение, которое Maven предлагает вам, использует SNAPSHOTS.

Я думаю, вы найдете некоторые преимущества, разбив кодовую базу на отдельные проекты:

  • Таким образом, Maven не будет запускать сборку в этих служебных модулях, когда она не нужна.
  • Если вы можете найти способ использовать стабильные выпуски для зависимостей, вы избежите многих хлопот.
  • Вы также можете разбить команду и заставить ее работать только с утилитами jars, чтобы сделать это на«основа по требованию» от команды, которая использует эти зависимости.
  • Если эти утилиты являются абстрактными или достаточно многократно используемыми, вы можете когда-нибудь найти другой проект, который может также использовать их без необходимости ссылаться на подмодуль от большегопроект.

В Интернете много дискуссий Maven обрабатывает зависимости (и другие вещи), и многие люди жалуются на те же проблемы, с которыми вы сталкиваетесь.По моему мнению, Maven - отличный инструмент, разработанный для того, чтобы сэкономить нам много времени при запуске новых проектов, но иногда он может быть немного громоздким.Я начал смотреть на другие инструменты, такие как Gradle , но теперь изменение инструмента сборки может быть хуже.Просто если дать идею взлома кодовой базы, иногда мы можем решить «проблему с программным обеспечением» с помощью небольшого «управления проектом» (или «управления портфелем» в данном случае).

2 голосов
/ 20 января 2012

Преимущество наличия единой версии для всех подмодулей - это простота, преимущество, которое не следует недооценивать.

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

Обрабатывая отношения стандартизированным способом с единой версией и развертывая в локальном репозитории после успешных сборок, вы сможете пользоваться управлением зависимостями так, как планировалось.

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

0 голосов
/ 27 января 2012

Я не чувствую, что придерживаться одной версии во всем проекте жизнеспособно на данном этапе, учитывая, что процесс сборки занимает так много времени прямо сейчас (на днях он потерпел неудачу после 7 часов !!).

Тем не менее, две ссылки ниже не полностью отвечают на мой вопрос, но находятся там:

...