У меня есть файл pom, который выглядит примерно так:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>myApp</groupId>
<artifactId>myAppId</artifactId>
<packaging>war</packaging>
<version>1.2-SNAPSHOT</version>
<name>Maven Test Webapp</name>
<url>http://maven.apache.org</url>
<dependency>
<groupId>com.manydesigns</groupId>
<artifactId>portofino-war</artifactId>
<version>3.1.10</version>
<type>war</type>
<scope>compile</scope>
</dependency>
</dependencies>
<build>
<finalName>TestName</finalName>
</build>
</project>
Если я запускаю 'mvn release: prepare' в приведенном выше файле pom, версия артефакта изменяется.то есть оно становится
<version>1.2</version>
Теперь предположим, что я перешел и обновил приложение portofino-war, которое является зависимостью этого pom-файла.portofino-war теперь имеет версию 3.1.11, но родительский файл pom указывает на версию 3.1.10, как показано выше.
Можно ли как-нибудь обновить родительский файл pom (через Maven или Jenkins), если будет создана новая версия portofino-war?
Спасибо
Редактировать
Приложение использует оверлеи Maven - http://maven.apache.org/plugins/maven-war-plugin/overlays.html для создания файла войны из других файлов войны.Это означает, что если какой-либо из зависимых модулей собран, родительский модуль должен быть собран для создания окончательного файла войны.
Проблема в том, что в настоящий момент, если я собираю какой-либо из модулей, мне нужновручную обновите версию в родительском файле pom для сборки, используя правильную версию модуля.
Редактировать 2
Спасибо за вашу помощь, Ральф.По сути, это то, чего я хотел бы достичь:
То, что я пытаюсь сделать, - это создать проект maven, который будет создавать файл войны, основанный на нескольких модулях.Предположим, что модули имеют следующую структуру:
Модуль 1
customerModule
|-webapp
|-jsp
|-customer
|-findCustomer.jsp
|-addNewCustomer.jsp
|-deleteCustomer.jsp
|-src
|-com
|-mycompany
|-customer
|-FindCustomerAction.java
|-AddCustomerAction.java
|-DeleteCustomer.java
Модуль2
productModule
|-webapp
|-jsp
|-product
|-productCustomer.jsp
|-addNewProduct.jsp
|-deleteProduct.jsp
|-src
|-com
|-mycompany
|-product
|-FindProductAction.java
|-AddProductAction.java
|-DeleteProduct.java
Модуль 3
commonModule
|-webapp
|-css
|-style.css
|-jsp
|-templates
|-coreTemplate.jsp
|-src
com
|-mycomany
|-common
|-Logger.java
|-Access.java
|-META-INF
|-MANIFEST.MF
|-context.xml
|-WEB-INF
|-lib
|-oraclejdbc.lib
|-log4j.lib
|-common.lib
|-struts-config.xml
|-tiles-def.xml
|-web.xml
Каждый из представленных модулейбудет разработан другой командой.Каждая команда создает файл войны и устанавливает его в локальный репозиторий Maven.В качестве примера, хранилище может выглядеть следующим образом:
com
|-customerModule
|-customerModule.v2.1.war
|-customerModule.v3.0.war
|-productModule
|-productModule.v3.0.war
|-productModule.v3.1.war
|-commonModule
|-commonModule.v0.5.war
|-commonModule.v3.0.war
Теперь менеджер компоновки использует указанные выше файлы war для создания окончательного развертываемого файла war.Первоначально я планировал использовать оверлеи maven для объединения трех военных файлов.Я протестировал объединение военных файлов с наложениями и обнаружил, что работает следующая конфигурация.то есть используя зависимости:
Примечание: эти зависимости находятся в файле pom commonModule
<dependency>
<groupId>com</groupId>
<artifactId>customerModule</artifactId>
<version>3.0</version>
<type>war</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com</groupId>
<artifactId>productModule</artifactId>
<version>3.1</version>
<type>war</type>
<scope>compile</scope>
</dependency>
Если я затем создаю модуль commonModule, я получаю один файл war, который содержит все содержимоеМодуль1, Модуль2 и Модуль3.Что в итоге выглядит примерно так:
MyApp.war
|-webapp
|-css
|-style.css
|-jsp
|-customer
|-findCustomer.jsp
|-addNewCustomer.jsp
|-deleteCustomer.jsp
|-product
|-productCustomer.jsp
|-addNewProduct.jsp
|-deleteProduct.jsp
|-templates
|-coreTemplate.jsp
|-META-INF
|-MANIFEST.MF
|-context.xml
|-WEB-INF
|-lib
|-oraclejdbc.lib
|-log4j.lib
|-common.lib
|-customerModule.jar
|-productModule.jar
|-classes
|-com
|-mycomany
|-common
|-Logger.class
|-Access.class
|-struts-config.xml
|-tiles-def.xml
|-web.xml
Вышеописанное работает, но для полного выпуска требуется немного ручного вмешательстваВот пример того, что произойдет, если модуль будет изменен
Модуль обновления Team 1 1
- Team 1 makes changes to module 1 and check in changes into CVS
- Team 1 installs module 1 onto the maven repository by issuing mvn:prepare and mvn:perform on module 1. This adds a new version of customerModule.war on to the local repository
- Team 1 updates the dependency version for module 1 in the pom file used to merge the war files (i.e. commonModule)
- Team 1 builds the deployable war file by building the commonModule.
Выше не используется многомодульный проект, как вы предложили, поэтому я пытаюсьпонять, как управление версиями будет работать с многомодульными проектами.Например, предположим, что многомодульный проект будет выглядеть следующим образом
MyApp
|- productModule
|-pom.xml
|- customerModule
|-pom.xml
|- commonModule
|-pom.xml
|-pom.xml
- В чем разница при добавлении номера версии в каждом дочернем модуле по сравнению с простым увеличением номера версии в родительском модуле?
- Вы говорите, что дочерние модули будут использовать родительскую версию.Допустим, родительская версия в настоящее время является версией 3.4, как она узнает, что предполагается использовать версию 3.1 productModule.war?
- И, наконец, если команда 1 внесла изменения в один из дочерних модулейНужно ли им собирать и развертывать его в репозитории maven как отдельный продукт, прежде чем создавать мультимодульный проект, или это можно сделать за один шаг?
- Как это будет работать, если я захочусделать выпуск патча, который не обязательно означает использование последней версии определенного модуля?
Спасибо