Как работать с Maven-версиями в многомодульном проекте? - PullRequest
Новая
       8

Как работать с Maven-версиями в многомодульном проекте?

6 голосов
/ 27 октября 2010

У меня есть инфраструктура проекта Maven, подобная этой: 

/trunk/all/pom.xml
/trunk/all/libs/lib1/pom.xml
               /lib2/pom.xml
               ...
/trunk/all/projects/p1/pom.xml
                   /p2/pom.xml
                   ...

Видите ли, у меня есть много библиотек и множество проектов, использующих эти библиотеки.

Все это объединено в один многомодульный проект, потому что мне нравится

  • импортировать лучший проект в Eclipse и иметь все мои библиотеки и проекты доступными одновременно
  • делает только один mvn test, чтобы скомпилировать и протестировать весь мой код после того, как я провел глобальный рефакторинг.

В настоящее время все мои модули имеют версию 1.0-SNAPSHOT.

Теперь я хочу выпустить проект p2 и все библиотеки p2 использует (например, lib1 и lib2) до версии 1.0. После этого я делаю некоторые модификации кода на lib1, но none на lib2.

Я хочу, чтобы следующим выпуском p2 была версия 1.1 с использованием lib1 в версии 1.1 (она была изменена с момента последнего выпуска), но lib2 все еще в версии 1.0 (так как не был изменен).

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

Вопрос

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

Ответы [ 2 ]

8 голосов
/ 28 октября 2010

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

Что ж, если вы не хотите синхронизировать версии различных артефактов (проектов, библиотек) с версией, определенной в all/pom.xml (т.е. просто наследовать ее по всей иерархии), боюсь, вы Придется начинать управлять ими вручную. Я просто не уверен, что пойму, почему вы не измените версию скажем lib2, даже если вы ничего не изменили. С вашей текущей структурой svn-репозитория все артефакты так или иначе имеют жизненный цикл релиза (когда вы пометите ствол, вы пометите все в нем).

Теперь, если p1 и p2 (для простоты я буду игнорировать библиотеки) имеют независимый цикл выпуска , я бы порекомендовал несколько "trunk / tags / branch" структура, как описано в этой теме : 

myrepo
  + .links (2)
    + trunks
      + pom.xml
  + parent-pom (1)
    + trunk
      + pom.xml
  + project-A
    + trunk
      + pom.xml
  + project-B
    + trunk
      + pom.xml

1) Родительское ПОМ проекта имеет собственный цикл выпуска. каждый POM компонента будет использовать его как родительский (ссылка просто с groupId и artifactId, нет relativePath). За релиз, который вы должны выпустить родитель POM первым.

2) Это конструкция для включения легко проверить выходы конкретной отрасли проекта, то есть обычно хобот. Пользователь Subversion проверяет myrepo / .links / trunk чтобы получить голову пересмотр всех источников. Хитрость в том, что этот каталог содержит внешние ссылки (т.е. с svn:externals собственности) к стволы всех других модулей этого проект (родитель-пом, проект-А, Проект-Б). Pom.xml в этом каталог никогда не выпускается, это содержит просто раздел модулей для три модуля, чтобы включить мульти сборка модуля. С этой конструкцией Вы можете легко настроить филиалы e.g.:

myrepo
  + .links
    + branch-2.x
      + pom.xml

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

Это не решит вашу «автоматическую» обработку версий (я не знаю никакого решения для этого), но, по крайней мере, эта структура прекрасно работает с Maven Release Plugin и будет поддерживать ваш независимый цикл выпуска требования.

Смотри также

Смежные вопросы

1 голос
/ 21 января 2011

HI! Может быть, я что-то упускаю, но если ваши libs / модули начинают чувствовать необходимость иметь свои собственные номера версий, разве это не признак того, что они взрослеют и ведут собственную жизнь - т.е. становятся отдельными проектами? по-своему?

То есть имеет смысл рассматривать их как таковые - рассматривать их как отдельные проекты, помещать в репозиторий mvn и добавлять в основной проект как обычные зависимости?

Извините, если я как-то упускаю из виду, но я сам сталкивался с "проблемами" многомодульного проекта ... и, возможно, проблема вообще не является проблемой?

...