Блог

Главная - Вопросы по программированию - Как настроить Jenkins для многомодульного проекта maven

Как настроить Jenkins для многомодульного проекта maven

#configuration #maven #jenkins #multi-module

#конфигурация #maven #Дженкинс #многомодульный

Вопрос:

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

 -modulA         (Main project)
   - pom.xml
-parentModul    (Aggregator)
   - pom.xml
   - ModulB     (Integration Test Project)
       -pom.xml

Определение пакета выглядит следующим образом:

 <project ...>
<modules>
    <module>../modulA</module>
    <module>ModulB</module>
</modules>

Один из модулей (ModulA) имеет тот же уровень иерархии, другой находится в родительском модуле.
Я пытаюсь добавить задание в Jenkins, чтобы все создавалось автоматически. (чистый пакет)..

Как мне настроить задание, чтобы parentModul находил другие модули и создавал проект.??

Комментарии:

1. Я немного растерялся после ваших комментариев. «ModuleA» имеет тот же уровень иерархии» — такой же, как и какой ? Фрагмент pom взят из «parentModul», верно? Если «ModuleA» проверяется в SVN отдельно, почему вы компилируете его с помощью «parentModule»? Наконец: в чем именно заключается ваше сообщение об ошибке?

Ответ №1:

Добавьте еще один агрегатор. Поместите modulA и parentModul в один каталог и на один уровень выше их, просто добавьте еще один pom, подобный этому:

 aggregator/
|- modulA/
|  |- pom.xml
|- parentModul/
|  |- modulB/
|  |  |- pom.xml
|  |- pom.xml
|- pom.xml

В aggregator/pom.xml определите раздел модулей следующим образом:

 <project ...>
    <modules>
        <module>modulA</module>
        <module>parentModul</module>
    </modules>
</project>

Комментарии:

1. Вы всегда можете реструктурировать / реорганизовать каталоги в SVN. На мой взгляд, то, что вы сделали, кажется неправильным.

Ответ №2:

Одним из решений было бы использовать SVN Externals для сборки разумного рабочего пространства проекта Maven из безумной структуры SVN даже на разных серверах svn. Использование svn external не является идеальным решением, поскольку это вызовет проблемы с плагином выпуска maven и с опросом SCM CI в определенной конфигурации. Они говорят вам: «Вы не должны использовать svn externals», что усложняет жизнь. Но так же поступают с leg cast и костылями, но когда у вас сломана leg (или структура svn, которая является fubar), вы действительно не возражаете против неудобств.

Существует несколько способов сделать это, в зависимости от вашей структуры SVN и желаемой структуры рабочей области:

  1. svn co modulA
  2. cd modulA
  3. svn propedit svn:externals . ПРИМЕЧАНИЕ: обратите внимание на точку (curdir) в конце строки!
  4. добавьте следующую строку: parentModul http://path.to.your.svn.location.of.parentModul
  5. svn ci -m «добавлены внешние элементы для родительского»
  6. svn up

и svn извлекает (и фиксирует) ваш код в следующей структуре рабочей области

 modulA/
|  |- pom.xml
parentModul/
|- modulB/
|  |- pom.xml
|- pom.xml
pom.xml

Или вы можете добавить новый каталог в SVN ‘workplace’ и добавить новый pom.xml там и получите все модули, которые вы когда-либо могли захотеть, через svn externals на один уровень (или на несколько уровней).

Ответ №3:

В моем случае невозможно добавить другой родительский проект. ModulA уже проверен в SVN независимо от других.

Это указывает на то, что вы, вероятно, ошибаетесь, добавляя moduleA <modules> раздел. Если moduleA имеет другой жизненный цикл, то вы должны включить его в качестве зависимости.

Метки: