Maven rada dotycząca wersjonowanie dużego projektu oraz unikania wersjach zawierających wyrażenia

Question

Patrzę na restrukturyzację dużego projektu Maven ...

Podstawowy przegląd naszej obecnej strukturze:

build [MVN plugins, third party dependency management]:5.1 
    NRW Utils:6.0.0.0-beta12-SNAPSHOT 
     server-utils:6.0.0.0-beta12-SNAPSHOT 
     ... 
    CMW Root:6.0.0.0-beta12-SNAPSHOT 
     cmw-webapp:6.0.0.0-beta12-SNAPSHOT 
     cmw-core [dependencies on NRW Utils]:6.0.0.0-beta12-SNAPSHOT 
     ... 
    NRW Root :6.0.0.0-beta12-SNAPSHOT 
     nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-beta12-SNAPSHOT 
     ... 

powodem zmiany:

wielkość każdego modułu zbiorowego (tj NRW Utils, CMW Korzeń Korzeń i NRW) jest coraz większe, a buil Proces ten zaczyna zajmować niewiarygodny czas (czasami około 4 godziny).

Nowy plan:

build [MVN plugins, third party dependency management]:5.1 
    NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT 
     server-utils:6.0.0.0-NU-beta4-SNAPSHOT 
     ... 
    CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT 
     ... 
    NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT 
     nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT 
     ... 

Rozpoczęliśmy wprowadzenie „klucze” w wersji do rozróżnienia pomiędzy różnymi modułami „zbiorowych” i stąd można łatwo wykonać schodkowe wydań. Ponadto nasze moduły narzędziowe są o wiele bardziej stabilne, więc nie musimy wymagać prawie tylu wersji beta - nie ma teraz żadnych ograniczeń dotyczących synchronizacji numerów wersji beta.

Warto również zauważyć, że w rzeczywistości istnieje 5 różnych "modułów zbiorczych" (nie tylko 3), które zostaną zbudowane w różnych wersjach (wyróżniających się unikatowymi klawiszami), dlatego pomyślałem, że byłoby miło mieć scentralizowane miejsce dla wersji, w przeciwieństwie do duplikatów właściwości w 5 różnych POM.

Problem polega obecnie na zawartości plików POM podczas definiowania zależności od modułów w innym "module zbiorczym" innej wersji.

Proponowane rozwiązanie do zarządzania zależnościami wersja:

build [MVN plugins, third party dependency management]:5.1 
    nrw-version-management:6.0.0.0-beta-SNAPSHOT 
     [contains properties defining latest versions of each collective module] 
     NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT 
     server-utils:6.0.0.0-NU-beta4-SNAPSHOT 
     ... 
     CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT 
     ... 
     NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT 
     nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT 
     ... 

NRW-version-zarządzanie (pom.xml):

... 
<parent> 
    <groupId>com.project</groupId> 
    <artifactId>build</artifactId> 
    <version>5.1</version> 
</parent> 
<groupId>com.project</groupId> 
<artifactId>nrw-versions-manager</artifactId> 
<version>6.0.0.0-beta-SNAPSHOT</version> 
<name>Version Maven Properties</name> 
<description>A centralised place for all module property versions</description> 
<packaging>pom</packaging> 
<properties> 
    <nrw.utilities.version>6.0.0.0-NU-beta4-SNAPSHOT</nrw.utilities.version> 
    <nrw.cmw.version>6.0.0.0-CMW-beta12-SNAPSHOT</nrw.cmw.version> 
    <nrw.version>6.0.0.0-NRW-beta9-SNAPSHOT</nrw.version> 
</properties> 
... 

CMW korzeni (pom.xml):

... 
<parent> 
    <groupId>com.project</groupId> 
    <artifactId>nrw-versions-manager</artifactId> 
    <version>${nrw.core.version}</version> 
    ... 
</parent> 
<groupId>com.project</groupId> 
<artifactId>CMW-root</artifactId> 
<version>6.0.0.0-CMW-beta12-SNAPSHOT</version> 
<packaging>pom</packaging> 
<dependencyManagement> 
    <dependencies> 
     ... 
     <dependency> 
      <groupId>${project.groupId}</groupId> 
      <artifactId>server-utils</artifactId> 
      <version>${nrw.utilities.version}</version> 
     </dependency> 
     ... 
</dependencyManagement> 
<profiles> 
    <profile> 
     <id>all</id> 
     <modules> 
      <module>cmw-webapp</module> 
      <module>cmw-core</module> 
      ... 
     </modules> 
    </profile> 
    ... 
</profiles> 
... 

N.B. właściwość $ {nrw.core.version} zostanie wówczas ustawiona na 6.3.0.0-beta-SNAPSHOT dla budowania migawki za pomocą argumentów wiersza poleceń (lub domyślnej wartości właściwości).

Ewentualny proces uwalniania (dla 6.0.0.0):

1. zbudować moduł 5.1 build jeśli nie jest już zbudowany
2. Konstruowanie NRW-version-zarządzanie 6.0.0.0 (w celu uniknięcia zależności Snapshot - jednak nie ma właściwości są jeszcze zmienić)
3. Budowa NRW Utils 6.0.0.0-NU cmd args: -Dnrw.core.version = 6.0.0.0
4. Budowanie CMW głównej 6.0.0.0-CMW cmd args: -Dnrw. core.versi on = 6.0.0.0 -Dnrw.utilities.version = 6.0.0.0-NU
5. Kompilacja NRW Root 6.0.0.0-NRW cmd args: -Dnrw.core.version = 6.0.0.0 -Dnrw.utilities.version = 6.0 .0,0-NU -Dnrw.cmw.version = 6.0.0.0-CMW
6. Ponowne utworzenie wersji-wersji-zarządzania 6.0.0.0 dla repozytorium cmd argumenty: -Dnrw.core.version = 6.0.0.0 -Dnrw.utilities.version = 6.0.0.0-NU -Dnrw.cmw. version = 6.0.0.0-CMW
7. Budowa NRW-version-zarządzanie 6.1.0.0 beta-SNAPSHOT nowe wersje dev i aktualizacji pliku POM

problem:

proces kompilacji wydaje długowieczny, szczególnie związany z modułem zarządzania wersją-wersją. Również zacząłem widząc to ostrzeżenie:

„wersja” zawiera wyrażenie, ale powinny być stałym

A zrobiwszy kilka bada teraz rozumiem wyrażenia nie są zalecane przy tworzeniu wersji (przy określaniu POM rodzic)

• Warning on using project.parent.version as the version of a module in Maven 3
• Maven: property substitution not done for /project/version tag of pom?
• http://maven.40175.n5.nabble.com/Pom-Parent-Version-Properties-td124576.html

pytania:

• mogę po prostu zignorować to ostrzeżenie? Niektóre posty zaczynają sugerować, że dopuszczalne jest podanie macierzystych wersji POM za pomocą właściwości.
• Czy to ogólne podejście jest konwencjonalne? Lub wadliwy?
• Czy istnieją lepsze rozwiązania dotyczące restrukturyzacji tego rosnącego projektu?

Z góry dziękuję.

Answer 1

Nie uważam, że trzymanie się jednej wersji w całym projekcie jest opłacalne na tym etapie, biorąc pod uwagę, że proces tworzenia trwa tak długo (teraz nie udało się to po 7 godzinach !!).

Jednak te dwa linki poniżej nie całkowicie odpowiedzieć na moje pytanie, ale są tam dostać:

• How to share common properties among several maven projects?
• How do I tell Maven to use the latest version of a dependency?

Answer 2

Zaletą posiadania jednej wersji dla wszystkich submodułów jest prostota, co nie powinno być niedoceniane.

Powinieneś zadać sobie kilka pytań, jeśli naprawdę chcesz polegać na różnych wersjach modułów w tej samej hierarchii. Jak zauważyłeś, wydanie staje się kłopotliwe.

Obsługując relacje w zestandaryzowany sposób z pojedynczą wersją i wdrażając do lokalnego repo po pomyślnych kompilacjach, powinieneś być w stanie cieszyć się zarządzaniem zależnościami tak, jak było to zamierzone.

Jeśli zmienisz projekt tak, aby był zgodny z konwencją wtyczki wydania, jego wydanie staje się proste.

Answer 3

Jak nico_ekito stwierdził w jednym z komentarzy, w moim własną opinię, teraz wpadacie w "koszmar zarządzania uzależnieniami". Zgodnie ze swoim scenariuszem ... czy faktem jest, że zarządzanie różnymi wersjami dla submodułów (a także odmienna stabilność kodu) jest symptomem tego, że te submoduły nie są już częścią dużego projektu?

To znaczy, my, jako ludzie, możemy jasno stwierdzić, że te moduły są częścią wielkiego obrazu, całego podejścia do rozwiązania problemu. Jest to dość powszechne, gdy okaże się, że twoje klasy narzędziowe nie mają zastosowania poza zakresem tego dużego obrazu. Ale z punktu widzenia Mavena myślę, że faktycznie zajmujesz się różnymi projektami, a nie modułami dużego.

Być może warto oddzielić bazy kodu w różnych strukturach i po prostu odwołać się do słoików narzędziowych z modułów, które faktycznie tego wymagają i po prostu użyć stabilnych kompilacji zamiast "ostatniej wersji tej zależności". W przypadku pracy ze stabilnymi kompilacjami nie jest to możliwe, ponieważ mimo tego, że kod dla tych zależności jest dość stabilny, ciągle się zmienia, a kod z innych modułów, a następnie rozwiązanie, które daje Maven, używa SNAPSHOTS.

myślę znajdziesz pewne korzyści, gdy łamiąc kod bazowy do odrębnych projektów:

• ten sposób Maven nie wywoła budować w tych modułów użytkowych, gdy nie jest potrzebny.
• Jeśli możesz znaleźć sposób na użycie stabilnych wersji dla zależności, unikniesz wielu kłopotów.
• Możesz także zerwać zespół i sprawić, by te działały z użyciem tylko słojów użytkowych, wykonując to na zasadzie "niedostatecznego popytu" od zespołu, który zużywa te zależności.
• Jeśli te narzędzia są wystarczająco abstrakcyjne lub nadają się do ponownego wykorzystania, możesz znaleźć inny projekt, który może je pochłonąć, bez potrzeby odwoływania się do modułu z większego projektu.

Istnieje wiele dyskusji w Internecie o drodze Maven handles dependencies (i innymi), a wielu ludzi narzekają tych samych problemów, przed którymi stoją. Moim zdaniem, Maven jest wspaniałym narzędziem, zaprojektowanym, aby zaoszczędzić nam dużo czasu przy rozpoczynaniu nowych projektów, ale czasami może być nieco kłopotliwy. Zacząłem szukać innych narzędzi, takich jak Gradle, ale teraz zmiana narzędzia do kompilacji może być gorszym rozwiązaniem. Pomijając ideę przełamania podstawy kodu, czasami możemy rozwiązać "problem z oprogramowaniem" tylko przy odrobinie "zarządzania projektem" (lub "zarządzania portfelem" w tym przypadku).