2012-09-26 22 views
5

Mam następujące projekty organizowane w płaskiej uporządkowany sposób:Maven projekt multi-moduł i Jenkins

parentProject 
+-pom.xml 

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

libraryA 
+-pom.xml 

libraryB 
+-pom.xml 

pom.xml wewnątrz parentProject ma odniesienia do innych modułów i jej stosować do spadków i dependencyManagement, tutaj jest fragment:

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

W Jenkins mam jedno zadanie maven dla każdego projektu, i to działa dobrze, kiedy budować parentProject, tj. buduje każdy projekt wymieniony w sekcji modules. Problem, który mam, kiedy zobowiązuję się do SVN zmiany w libraryA, oczekiwałbym, że po zbudowaniu biblioteki A, przebuduje się na projectWeb, która ma zostać uruchomiona, ale tak się nie stało. Ktoś wie, co robię źle?

Z góry dziękuję.

EDIT

Kiedy usunąć sekcję modules z parentProject\pom.xml, to działa jak espected, ale tracą przewagę agregacji o pom nadrzędnego.

Odpowiedz

0

To powinno być skonfigurowane w pracy Jenkins. Patrz „libraryA pracy”/„Konfiguracja”/„Budowanie wyzwalaczy”/„Zbuduj po inne projekty są budowane”

+0

Dziękuję za odpowiedź, ale gdy wstawiam edytowane pytanie: Jeśli usuwam moduły z macierzystej pom, kompilacje są uruchamiane zgodnie z oczekiwaniami, tj. Jeśli zbuduję 'libraryA', to' proyectWeb' jest budowane automatycznie, bez konfiguracji wspomniałeś. – sivainvi

1

Wygląda na to pytasz swoją macierzystą POM zrobić dwie rzeczy:

  1. Skonfiguruj zarządzanie zależność rzeczy
  2. Kruszywo Twój build

to generalnie lepiej, jeśli to podzielić się na dwie poms - Pom dominującej za # 1 i zagregowanej pom dla # 2. Można by potem mieć coś takiego ..

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

Zobacz tę odpowiedź więcej szczegółów: https://stackoverflow.com/a/3301162/211993

którą następnie skonfigurować Jenkins sprawdzić root dir i uruchom „mvn czystej instalacji”

+2

Czy możesz wyjaśnić, dlaczego "Generalnie lepiej jest, jeśli podzielisz ..."? Nie mówię, że to nie jest, ale nie rozumiem, dlaczego jest lepiej. Niestety nie zrozumiałem tego z odpowiedzi, do której masz link. Dzięki! – Ittai

+1

Początkowo pomaga to tylko w rozdzielaniu problemów - agregator odpowiada za kolejność tworzenia modułów, rodzic jest odpowiedzialny za wersje zależne i takie, jak szczegóły połączenia scm. – dan

+1

Widziałem również przykłady, w których ludzie rozbili swoją mateczkę na części wspólne, które następnie stają się rodzicami innych poms-matek. Załóżmy na przykład, że masz kilka projektów, które używają Hibernacji, możesz przeciągnąć tę garstkę wersjonowania do macierzystej pom hibernacji, a następnie użyć tego jako "super rodzica" (jak to się stało, właśnie zrobiłem to zdanie) zapewniające spójne wersje biblioteki hibernacji w wielu projektach, które nie są w inny sposób połączone. Ale upewnij się, że rzeczywiście chcesz tego wspólnego podejścia; łączycie wiele projektów razem, co może nie być pożądane. – dan