Многомодульный проект Maven и Jenkins

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

parentProject
+-pom.xml

projectWeb <depends on libraryA and libraryB>
+-pom.xml

libraryA
+-pom.xml

libraryB
+-pom.xml

Pom.xml внутри parentProject имеет ссылки на другие модули и используется для наследования и dependencyManagement, вот фрагмент:

<project>
    ....
    <modules>
        <module>../projectWeb</module>
        <module>../libraryA</module>
        <module>../libraryB</module>
    </modules>
    <dependencyManagement>
    ...
    </dependencyManagement>
    <build>
    ...
    </build>
    ....
</project>

В Jenkins у меня есть одно задание maven для каждого проекта, и оно отлично работает, когда я создаю parentProject, т.е. строит все проекты, указанные в разделе modules. Проблема, с которой я сталкиваюсь, заключается в том, что когда я фиксирую в SVN изменение в libraryA, я ожидал, что после сборки libraryA будет запущена перестройка в projectWeb, но этого не произошло. Кто-нибудь знает, что я делаю не так?

Заранее спасибо.

ИЗМЕНИТЬ

Когда я удаляю раздел modules из parentProject\pom.xml, он работает должным образом, но я теряю преимущество агрегирования, связанное с наличием родительского pom.


jenkins java maven multi-module
person Diego Sergnese    schedule 26.09.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Похоже, вы просите родительский POM сделать две вещи:

  1. Настроить управление зависимостями
  2. Агрегируйте свою сборку

Как правило, лучше, если вы разделите его на два помпона - родительский помпон для №1 и совокупный помп для №2. Тогда получится что-то вроде ..

[root dir] aggregate pom.xml
+ /parent 
+ /web
+ /libA
+ /libB

Подробнее см. В этом ответе: https://stackoverflow.com/a/3301162/211993

Затем вы должны настроить Jenkins для проверки корневого каталога и запустить «mvn clean install».

person dan    schedule 29.10.2012
comment
Не могли бы вы уточнить, почему в целом лучше, если вы разделитесь ...? Я не говорю, что это не так, но я не понимаю, почему так лучше. К сожалению, я не понял этого из ответа, на который вы указали. Спасибо! - person Ittai; 11.11.2012
comment
Итак, изначально это просто помогает с разделением проблем - агрегатор отвечает за порядок сборки модулей, родительский отвечает за версии зависимостей и такие вещи, как детали соединения scm. - person dan; 25.01.2013
comment
Кроме того, я видел примеры, когда люди разбивали свои родительские помпы на общие части, которые затем становились родителями для других родительских помп. Скажем, например, у вас есть пара проектов, в которых используется Hibernate, вы можете перетащить эту кучу управления версиями в родительский pom спящего режима, а затем использовать его в качестве суперпродителя (так сказать, я только что придумал эту фразу), давая вы согласовываете версии библиотеки гибернации в нескольких проектах, которые иначе не связаны. Но убедитесь, что вам действительно нужен такой общий подход; вы объединяете несколько проектов, что может быть нежелательно. - person dan; 25.01.2013
comment
Или вы можете разбить его на группу супер-родителей, которыми никогда не делятся, вы просто делаете это для удобства чтения. Честно говоря, я никогда не заходил дальше единственного родителя и единственного агрегатора, но я считаю, что это намного чище, чем родительский и агрегатор в одном. - person dan; 25.01.2013

arrow_upward
0
arrow_downward

Это должно быть настроено в задании jenkins. См. «Задание libraryA» / «Конфигурация» / «Триггеры сборки» / «Сборка после сборки других проектов».

person alexei-grigoriev    schedule 27.09.2012
comment
Спасибо за ответ, но, как я задал отредактированный вопрос, если я удалю модули из родительского pom, сборки будут запущены, как ожидалось, то есть, если я построю libraryA, тогда proyectWeb будет построен автоматически, без конфигурации, о которой вы упомянули. - person Diego Sergnese; 27.09.2012