# Wie sind Multi-POM Maven Projects zu verwalten/releasen



## ArkLut (10. Mrz 2019)

Hi,


Ich kenne Multi Pom maven projecte bei denen alle die Version des parents haben.

Diese sind etwa so strukturiert, dann erben die child poms die Version und damit die module/jars:


Parent:

```
<groupId>com.example.apps</groupId>
    <artifactId>megaApp</artifactId>
    <packaging>pom</packaging>
    <version>1.2.3-SNAPSHOT</version>
    <name>super application</name>
    <modules>
        <module>megaApp-assembly</module>
        <module>megaApp-config</module>
        <module>megaApp-common</module>
        <module>megaApp-persist</module>
        <module>megaApp-webapp</module>
        <module>megaApp-service</module>
        <module>megaApp-ear</module>
    </modules>
```


Childs:

```
<parent>
        <groupId>com.example.apps</groupId>
        <artifactId>megaApp</artifactId>
        <version>1.2.3-SNAPSHOT</version>
        <relativePath>../pom.xml</relativePath>
    </parent>

    <artifactId>megaApp-config</artifactId>
    <name>megaApp-CONFIG</name>
    <description>megaApp Configuration</description>
```

Das ist für mich kein Problem.

aber ich bin jetzt über einige gestoßen bei denen die einzelnen Sub Module eigene Versionen haben.
was ich mich dabei frage wie man die releaset?

Bei den mit gemeinsamer Version ist es klar - man kann nur alle gemeinsam releasen - macht auch anders kaum sind - dafür gibt es aber keine Probleme.

aber bei denen mit einzelnen Versionen? 
Klar der Vorteil wäre ich kann sie einzeln releasen und so muss ich nicht alles neu releasen wenn es nur in einem eine Änderung gibt.
ABER wenn es eine Änderung gibt muss ich ja auch die abhängenden neu releasen – der Vorteil geht (zum teil) verloren. (mMn völlig, da es mehr denk aufwand ist und das Maven Release Plugin das glaube ich nicht kann)
das ist insbesondere blöd wenn im parent gemeinsam die Versionen von Abhängigkeit definiert sind (in den Properties) – das alle die gleichen haben.

wie seht ihr das?

ich bin grade auf ein solches Project gestoßen - und versuche zu durchschauen wie ich das geordnet releasen kann.


----------



## dzim (11. Mrz 2019)

Also wir machen mehr oder weniger so: Wird ein Modul, z.B. das Modell, verändert, wird dessen Version angepasst und die aller Dependencies meist nur im Patch. Das liegt aber auch konkret daran, das wir in einem Maven-Projekt mehrere Applikationen haben (darüber ob das jetzt sauber ist, *kann* man streiten, mich stört es nicht...), die im Prinzip "continuous" released werden.

Wir haben aber im Kontrast dazu auch ein grosses Projekt, bei dem alle, die das Parent verwenden, dessen Version nutzen - macht dort Sinn, weil dass nur nach speziellen Vorgaben released (vielleicht 1-2 Mal pro Jahr) wird.

Es ist also absolut abhängig vom Use-Case, finde ich.


----------



## mihe7 (11. Mrz 2019)

Wir machen das noch einfacher: wir haben keine Versionsnummern (d. h. die im POM angegebene Version existiert nur pro forma) 

Stattdessen verwendet Jenkins beim Build ein anderes Profil, das aus unterschiedlichen Werten eine dem Commit zuordenbare Versionsnummer generiert und in die Anwendung integriert...


----------



## dzim (12. Mrz 2019)

@mihe7 So kann man es auch machen. In unseren Maven-Builds wird i.d.R. ein Manifest-Entry mit dem Git-Hash injeziert. Bei einer JavaFX GUI von uns läuft im Maven ein Ant-Task (frag nicht...), der den Git-Hash in eine generierte Klasse einträgt, die dann im GUI verwendet wird.


----------



## mihe7 (12. Mrz 2019)

Ja, so in etwa ist das bei uns auch, nur nehmen wir das git-commit-id-plugin und kein ant her  Die Versionsnummer besteht dann aus Datum, Uhrzeit und Git-Hash


----------



## dzim (12. Mrz 2019)

Für den Git-Hash nutzen wir das auch, aber um die Datei zu manipulieren nutze ich den Ant-Task (weil das damit erschreckenderweise einfacher geht, als mit Maven-Bordmitteln, ohne eigene Plugins schreiben zu müssen).


----------



## mihe7 (12. Mrz 2019)

Das wiederum läuft bei uns über Resource-Filter. Es gibt eine Datei version.properties die enthält einen Key application.version=${version.number} und das wars


----------



## dzim (12. Mrz 2019)

Ah... Der Resource-Filter hat mich aber auch schon man in den Wahnsinn getrieben: Versuch ihm mal beizubringen, dass er (in einer Java 8-Umgebung) Property-Dateien für Übersetzungen **nicht** nach UTF-8 formatieren darf, alle anderen schon. Und nein: In-/Excludes bringen nichts! Ich musste einen eigenen Resource-Ordner definieren. (Bei uns wird übers Profil der Log-Level im log4j2.xml auf diese Art angepasst.)
Aber Grundsätzlich hast du recht: Ein Property-Datei-Template im Resource anzupassen und im Code einfach zu lesen, ist deutlich besser. Aber das Projekt fing for einigen Jahren, als ich noch nicht mit Maven klar kam, rein als Ant-Build an... Shame on me.


----------



## mihe7 (12. Mrz 2019)

dzim hat gesagt.:


> Shame on me.


Genau!


----------



## dzim (12. Mrz 2019)




----------



## mrBrown (12. Mrz 2019)

dzim hat gesagt.:


> Versuch ihm mal beizubringen, dass er (in einer Java 8-Umgebung) Property-Dateien für Übersetzungen **nicht** nach UTF-8 formatieren darf, alle anderen schon. Und nein: In-/Excludes bringen nichts! Ich musste einen eigenen Resource-Ordner definieren.


Da macht Maven doch alles richtig: Nutzer so lange quälen, bis dafür endlich UTF-8 genutzt wird


----------



## dzim (12. Mrz 2019)

Ja, oder man auf Java 9+ umsteigt, wo UTF-8 in solchen Properties kein Problem mehr darstellen. Hab ja eigentlich auch nie verstanden, warum die bei den Dateien da so eine Encoding-Extrawurscht gemacht haben. Hab schon wirklich mal überlegt, ne eigene ResourceBundle-Impl zu schreiben, die JSON als Properties verwendet. Oder noch besser HOKON.
Aber gibt's vermutlich alles schon...


----------



## mihe7 (12. Mrz 2019)

dzim hat gesagt.:


> Hab ja eigentlich auch nie verstanden, warum die bei den Dateien da so eine Encoding-Extrawurscht gemacht haben.


Das ist allerdings eine berechtigte Frage. Java arbeitet(e) intern mit UTF-16, berücksichtigt an jeder Ecke die Arbeit mit verschiedenen Encodings aber genau an der Stelle, wo es um Internationalisierung geht und damit ein SBCS ganz offensichtlich nicht ausreicht, legt man sich dann auf ISO-8859-1 fest. WTF?!?


----------

