Иерархия maven проектов без разброса номера версии

Question

Если вы используете Maven2 в качестве системы сборки для проекта, содержащего много артефактов с одинаковым номером версии, версия полученной сборки будет разбросана по всем файлам pom.xml. Во многих из них даже дважды - в теге версии самого артефакта и в теге версии родительского элемента. Таким образом, вы должны изменить и зарегистрировать новые версии всех pom.xml при каждом переключении версий. Это несколько раздражает, особенно если вам приходится писать код для исправления нескольких ошибок и разработки версии параллельно. Есть ли способ обойти это?

УТОЧНЕНИЕ: Мой вопрос касается множества версий каждого отдельного файла pom.xml, которые вы получаете со временем в вашей системе контроля версий, которые отличаются только номером версии pom и / или номером версии родительского pom. В идеале вам нужно менять помп только тогда, когда вы добавляете зависимость или что-то в этом роде.

Например, у вас есть проект с артефактами foo-pom (родительский pom для всех), foobar-jar, foobaz-jar и foo-war. В первом выпуске версия 1.0 - которая появляется в каждом pom.xml. Во втором выпуске версия 1.1 - которая снова появляется в каждом pom.xml. Таким образом, вы должны изменить каждый файл pom.xml - это раздражает, если вы выпускаете так часто, как должны.

ОБНОВЛЕНИЕ: Если вы считаете это важным: отсутствие необходимости указывать родительскую версию уже рассматривается. Перейдите к выпуску maven JIRA и проголосуйте за него, чтобы сделать его более заметным и с большей вероятностью добавленным в качестве усовершенствования в следующем выпуске. Для этого вам необходимо создать / иметь логин JIRA.

Существует еще один вопрос Stackoverflow , который в основном касается той же проблемы.

Answer 1

Есть еще один поток StackOverflow, который также охватывает эту тему, на которую вы можете посмотреть .

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

Answer 2

Я столкнулся с подобными проблемами, работая над большой системой, созданной с помощью Maven 2.

На мой взгляд, недостатком типичной многомодульной структуры является то, что все модули должны поделиться той же версией. Это действительно раздражает: даже если ваш следующий выпуск состоит только из исправления в foobar-jar, вам нужно изменить глобальную версию везде (будь то вручную или с помощью maven-release-plugin) и выпустите новую версию каждого компонента. В моем случае я создавал различные приложения WAR / EAR, поэтому мой клиент спрашивал меня, почему я поставил новую версию app1 и app2, когда предполагалось, что это повлияет только на app1.

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

Я долго думал о том, как объединить оба подхода: гибкость независимых версий, не отказываясь от глобальной согласованности системы. Я попробовал тот же подход, что и romaintaz, и столкнулся с той же проблемой. Наконец, я пришел к этой идее: http://out -println.blogspot.com / 2008/10 / Maven-модули-с-независимым-versions.html .

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

Answer 3

Предоставляет ли эта статья решение вашей проблемы?

Идея состоит в том, чтобы объявить номер версии для всего проекта как свойство, а именно «отвращение» (каламбур), в родительском pom. Номер версии родительского pom может быть любым, если он заканчивается на «SNAPSHOT».

Версия дочерних модулей указывается через свойство $ {aversion}. Ссылка детей на версию их родителей жестко закодирована. Однако, поскольку версия родительского pom является SNAPSHOT, дочерние модули увидят изменения в родительском pom. В частности, если родительский pom изменит значение $ {aversion}, дети увидят это изменение.

Не идеальное решение по комментариям.

И плагин релиза не решает реальную проблему: слияние .
Наличие бесконечных копий номера версии повсеместно означает много конфликтов при объединении ветвей.

Примечание:

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

Answer 4

У меня на проекте такая проблема. Чтобы уменьшить количество версий, я определяю в своем родительском файле pom.xml некоторые свойства, которые соответствуют версиям каждого модуля:

<properties>
    <project-version>1.0.0</project-version>
    <!-- Same version than the parent for the module 'commons' -->
    <project-commons-version>${project-version}</project-commons-version>
    <!-- A specific version for the 'business' module -->
    <project-business-version>1.0.1</project-business-version>
    ...

И затем, в pom.xml каждого модуля, я использую эти свойства. Проблема в том, что я должен четко указать версию родителя в этом файле pom.xml. Например, в моем бизнесе pom.xml у меня есть:

<project>
  <modelVersion>4.0.0</modelVersion>
  <!-- I must indicate the version of the parent -->
  <parent>
    <groupId>my.project</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>
  ...
  <dependencies>
    <!-- However, in my dependencies, I use directly the properties defined in the parent's pom.xml -->
    <dependency>
      <groupId>my.project</groupId>
      <artifactId>project-persistence</artifactId>
      <version>${project-persistence-version}</version>
    </dependency>

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

Answer 5

Это идея для возможного расширения maven, которое решило бы проблему. В настоящее время вы должны записать версию артефакта и родительского pom в pom.xml. Уже есть способ указать абсолютное местоположение родительского pom:

<parent>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>my-parent</artifactId>
    <version>2.0</version>
    <relativePath>../my-parent</relativePath>
</parent>

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

Answer 6

У нас есть именно эта проблема. У нас есть большое количество (около 10) различных проектов, некоторые из которых зависят друг от друга. Папка, содержащая проекты, имеет родительский pom для всего набора проектов. Каждый раз, когда мы создавали новую ветвь, нам приходилось заходить в каждый файл pom, чтобы изменить элемент , а также для родителя, и все это редактирование раздражало.

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

К сожалению, я забыл сказать коллеге, что это невозможно, поэтому он исправил это. Его решением было добавить свойство в родительский файл pom:

<properties><currentVersion>2.6.1-SNAPSHOT</currentVersion></properties>

Затем в дочерних pom-файлах мы объявили тег родительской версии следующим образом:

<version>${currentVersion}</version>

Я не знаю, почему это работает. Я не вижу, как он может найти правильный родительский pom без указания номера версии. Но для меня (maven версия 1.5.0_22) работает.

Answer 7

Вот еще один легкий обходной путь, пока проблема maven не будет решена. В одном большом проекте мы больше не помещаем сам pom.xml в элемент управления версиями, а добавляем pom-template.xml, который просто содержит заполнитель для номера версии. После обновления дерева проекта из системы управления версиями вам нужно запустить небольшой скрипт ant, который генерирует фактический файл pom.xml в каждом каталоге. Это раздражает, но менее раздражает, чем приходится мириться со всеми этими надоедливыми версиями POM.