Przepraszam za długość tego postu, ale miałem problem z tym, żeby był bardziej zwięzły, bez przedstawienia obrazu. Niedawno odziedziczyłem pracę nad kompilatorem dla wielomodułowego projektu maven 3.0. Problem polega na tym, że struktura projektu / modułów jest katastrofą. Od sposobu, w jaki rzeczy są obecnie przechowywane w Kontroli źródła (używamy RTC), do struktury pom modułów, wyrywam sobie włosy, próbując uzyskać za każdym razem pełny cykl budowy.

W miarę rozwoju hierarchii wszystkie moduły są przechowywane „płaskie”; tj .: wszystko jest na tym samym poziomie. Mam rodzica pom, a wszystkie moduły zależą od rodzica. Jednak rodzic jest na tym samym poziomie, co wszystkie inne moduły.

Dawny:

<code>c:\dev\MyEarProject
 + parent-pom
   - pom.xml
 + module1
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module2
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module3
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
</code>

Nadrzędny pom definiuje wszystkie moduły wymagane do zbudowania projektu, a także zestaw właściwości dla numerów wersji artefaktów używanych w różnych submodułach:

<code><modules>
  <module>../module1</module>
  <module>../module2</module>
  <module>../module3</module>
</modules>

<properties>
    <org.springframework.version>3.0.5.RELEASE</org.springframework.version>
    <slf4j.version>1.6.4</slf4j.version>
    <repositoryAddress>${snapshots.repo.url}</repositoryAddress>
    <my.hibernate-module.dao.impl>1.2.3</my.hibernate-module.dao.impl>
    <my.hibernate-module.dao.api>1.2.3</my.hibernate-module.dao.api>
</properties>
</code>

Pom z każdego modułu zależy z kolei od rodzica pom za pośrednictwem numeru artefaktu pom:

<code><parent>
    <groupId>com.cws.cs.lendingsimulationservice</groupId>
    <artifactId>parent-pom</artifactId>
    <version>1.0.6</version>
</parent>
</code>

Aby uczynić rzeczy jeszcze bardziej mylącymi, rzeczywista nazwa artefaktu może (lub nie musi) (w zależności od modułu) pasować do ścieżki modułu. Na przykład moduł 1 może znajdować się w ścieżcec:\dev\MyEarProject\module1 ale mają nazwę artefaktuhibernate-module. Jednak ze względu na sposób przechowywania w RTC katalog jest wywoływanymodule1 kiedy zostanie wyrejestrowany.

Najprostszym sposobem na zbudowanie wszystkiego, oczywiście, jest wejściec:\dev\MyEarProject\parent-pom\ i biegnijmvn clean deploy. Działa to dobrze, gdy w trybie SNAPSHOT repo SNAPSHOT pozwala na wiele wdrożeń tej samej wersji artefaktu. Ale w trybie zwolnienia to się nie powiedzie.

Ta struktura powoduje dla mnie 2 problemy.

Za każdym razem, gdy muszę zmienić wersję na właściwość rodzica, muszę zaktualizować numer wersji parent-pom, a wszystkie moduły potomne nadrzędne wersji pom, a wszystkie wersje modułów potomnych same (ponieważ rodzic się zmienił).Ilekroć muszę wdrożyć cykl wydań, mvn zgłosi błąd, jeśli jeden z modułów nie uległ zmianie od ostatniego cyklu i w związku z tym nie można go ponownie zastosować do tego samego repo (repo nie pozwala na zastąpienie istniejących artefaktów)

Więc szukam najlepszego sposobu na restrukturyzację tego projektu, aby uniknąć tych problemów. Dla rodzica pom wiem, że mogę użyć ścieżki względnej, aby wskazać na rodzica. Jednakże, biorąc pod uwagę „płaską” strukturę modułów, czy jest to zalecane podejście (tj. Ścieżka względna pom-pom byłaby ../parent-pom/pom.xml - wydaje mi się trochę dziwna)? Dodatkowo, biorąc pod uwagę, że kontrola wersji nadrzędnej jest niezależna od modułów, użycie ścieżki względnej nie tylko otworzy drzwi do dodatkowego zamieszania (tj .: nie byłoby sposobu, aby dowiedzieć się, która wersja nadrzędnego pom jest powiązana z którą wersją podmodułu).

Po drugie, jak mogę zbudować całe ucho bez napotkania błędów wdrażania? Ponieważ artefakt już istnieje w repozytorium, nie muszę go odbudowywać i ponownie wdrażać. Próbowałem użyć --projects, ale przy ilości zaangażowanych modułów zarządzanie nimi jest niezwykle trudne.