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

Ответ 1

Там fooobar.com/questions/144990/....

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

Ответ 2

У меня возникли аналогичные проблемы при работе с большой системой, построенной с помощью Maven 2.

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

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

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

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

Ответ 3

В моем проекте у меня такая проблема. Чтобы уменьшить количество версий, я определяю в своем родительском 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 pom.xml -->
    <dependency>
      <groupId>my.project</groupId>
      <artifactId>project-persistence</artifactId>
      <version>${project-persistence-version}</version>
    </dependency>

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

Ответ 4

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

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

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

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

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

Примечание:

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

Ответ 5

Это идея возможного расширения maven, которая решила бы проблему. В настоящее время вам нужно написать версию артефакта и родительского пом в 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 по относительному пути, вы закончили. Версия упоминается только в родительской папке и нигде больше.

Ответ 6

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

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

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

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

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

<version>${currentVersion}</version>

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

Ответ 7

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