Maven с Jenkins - обновить родительскую версию зависимости - PullRequest
3 голосов
/ 12 марта 2012

У меня есть файл 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 как отдельный продукт, прежде чем создавать мультимодульный проект, или это можно сделать за один шаг?
  • Как это будет работать, если я захочусделать выпуск патча, который не обязательно означает использование последней версии определенного модуля?

Спасибо

Ответы [ 2 ]

3 голосов
/ 12 марта 2012

Для сценария, описанного в части вопроса «Изменить», я бы порекомендовал поместить все военные файлы в один: многомодульный проект.

3 голосов
/ 12 марта 2012

Вы можете использовать диапазон зависимостей вместо обновления pom: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...