maven релиз плагин и несколько проектов в отдельных хранилищах git с Jenkins

Question

Я нашел немало намеков о 0MB, 0M, MULL, многопроектных, родительских POM и т. Д., Но все они не совсем соответствуют тому, что я есть:

у меня есть несколько проектов (уменьшенный случай два: project-common и project-impl), которые несколько отдельно друг от друга, и разработан в отдельных GIT хранилищ, но обычно выпускается вместе. Для этой цели project-common/pom.xml содержит:

<groupId>de.tarent.example</groupId> 
<artifactId>project-common</artifactId> 
<version>1.5.1.4-SNAPSHOT</version> 

... и project-impl/pom.xml содержит:

<groupId>de.tarent.example</groupId> 
<artifactId>project-impl</artifactId> 
<version>1.5.1.4-SNAPSHOT</version> 

<dependencies> 
    <dependency> 
     <groupId>de.tarent.example</groupId> 
     <artifactId>project-common</artifactId> 
     <version>${project.version}</version> 
    </dependency> 

Существует нет родитель POM.

Идея здесь состоит в том, чтобы обычно использовать версию project-common для всех, но иметь возможность делать отдельные релизы только одного проекта; в этих случаях версия зависимости, конечно же, должна быть изменена вручную, но это нормально.

Теперь мы используем Jenkins «Perform Maven Release» для создания наших релизов. (Ну, мы хотим. Проекты до недавнего времени не были выпущены, поэтому наши разработчики построили их вручную, в комплекте с временными файлами, неиспользуемыми файлами, локальными изменениями, паролями LDAP в конфигурациях XML, редакторами .swp и т. Д. - вы можете видеть поэтому мне было поручено изменить это, несмотря на не зная Java ™ или Maven или Дженкинс. или, может быть, из-за него.)

выпуск project-common идет без сучка и задоринки, но project-impl терпит неудачу в самом первом чтобы убедиться, что нет зависимостей SNAPSHOT. Хорошо, дух. (Нет ни одного, кроме project-common.) Переопределение maven-release-plugin, чтобы пропустить проверку SNAPSHOT невозможно. Использование родительского ПОМ здесь тоже не работает, так как это полностью отдельные репозитории и, иногда, освобождаются независимо. Итак, как это сделать, сохраняя комфорт Jenkins и Maven Release?

Продолжить на: Ответ на свой вопрос - поделитесь своими знаниями, Q & A-стилем ...

Answer 1

журналов для чтения, я понял, что Дженкинс вызывает Maven так:

mvn -B -f /var/lib/hudson/jobs/project-impl/workspace/pom.xml \ 
    -DdevelopmentVersion=1.5.1.5-SNAPSHOT -DreleaseVersion=1.5.1.4 \ 
    -Dtag=1.5.1.4 -Dresume=false release:prepare release:perform \ 
    -DpreparationGoals=clean install -e 

-D было быть хорошим для чего-то, не так ли? Могу ли я сделать ${project.version:-${releaseVersion}}, как в оболочке, я спросил сотрудника (спасибо Умер!), Который сказал, не так, но -D переопределяет свойства.

Это остановило меня на короткое время: я не мог поместить версию в свойство, потому что maven-release-плагин обновляет только проект <version>.

К счастью, двойное косвенное действие работает.В то время как уродливый рубить, и это будет перерыв, если кто-то не использует Дженкинс освободить, или если кто-то использует -DreleaseVersion локально, две небольшие изменения сделали эти проекты разборных:

во-первых, мы добавим свойство releaseVersion, который по умолчанию (динамически обновляется) ${project.version}:

<properties> 
    <releaseVersion>${project.version}</releaseVersion> 
</properties> 

Затем мы изменим зависимость, чтобы использовать его вместо:

<dependency> 
     <groupId>de.tarent.example</groupId> 
     <artifactId>project-common</artifactId> 
     <version>${releaseVersion}</version> 
    </dependency> 

единственный проблема, которую я вижу в этом решении, заключается в том, что некоторые {one, thing} используют выпущенный POM из репозитория Maven, так как он также содержит эту косвенность (мы не фильтруем POM при выпуске). Но он работает хорошо, до сих пор.

И если есть необходимость в project-impl, один будет просто изменить <version>${releaseVersion}</version> линию <version>1.5.1.4</version> вручную, так же, как и раньше (при прочих равных условиях ).