Java Parent-Pom ?!?

[KeepCalm]

Hallo zusammen,
also das ist nun ein absolutes Hardcore Nerd Thema im Enterprise Entwicklungsumfeld, wenn einer nicht auf Anhieb weis, was eine Parent-Pom ist muss sich nicht die Mühe machen, weiter zu lesen.

Jedesmal, wenn ich ein Greenfield-Projekt im SpringBoot Umfeld (es wären Microservices) habe und es abzusehen ist, das es mehrere, ähnliche geben wird stelle ich mir die Frage mache ich eine Parten-Pom für's Team oder nicht ?

Mein vorgehen ist eigentlich start.spring.io .. Rahmen zusammen klicken und dann ergänzen .. und da ich relativ aktuelles Wissen habe, bereitet mir das auch nicht so die Probleme

also .. für die Kollegen eine Parent-Pom

• das Wissen hat nur die Person, wer den Parent macht
• bei Updates (log4j) warten alle dann auf genau den
• die Kollegen können sich zurücklehnen, denn irgendwelche Migrationen macht ja der, der das Wissen hat.

keine Parent-Pom

• die Entwicklung eines Services dauert mit unter was länger
• Updates muss jeder selber machen und auch migireren
• Wissen dazu müssen alle aufbauen.

und nun bin ich echt auf Meinungen gespannt dazu

 

[honky-tonk]

ich kenne es so, dass alle wichtigen libs in der parent pom sind und dann bei nem update alle unterprojekte gleichzeitig auf die selbe version gezogen werden...und es muss halt nur 1mal passieren, also pro parent pom ;-)

 

[SaxnPaule]

das Wissen hat nur die Person, wer den Parent macht

vs.

Wissen dazu müssen alle aufbauen.

Gerade das ist mMn ein Grund gegen eine PP. Silowissen ist immer zu vermeiden und ein Busfaktor von 1 ist auch schlecht.

In der Regel weiß man doch welche Deps man benötigt. Die sind doch dann fix in der Pom eingetragen.

Einzig die Update Thematik sehe ich als hinderlich. Da kann man aber evtl. was in Sonar einbauen, so dass der Build nicht durchgeht wenn eine Library critical issues hat oder outdated ist.

 

[KeepCalm]

Für die Update Thematik gibt es z.B. so etwas wie DependaBot

 

[dermoritz]

TL;DR

ich rate insbesondere im Spring Boot Zusammenhang von einer weiteren parent pom ab:

Erklärung für die "anderen"

Also die POM steht für "Project Object Model" es ist das Model auf dem "Maven" aufsetzt. Lange Zeit das unangefochtene Build-System für Java. Es hat "Ant" abgelöst und bekommt/hat nun große Konkurenz durch "Gradle"

Das Prinzip von Maven ist "deklerativ", man beschreibt nicht was es tun soll, sondern man sagt was das Endergebnis ("Goal") sein soll. z.B. "Package" -> erzeugt eine jar-Datei und führt vorher alle Tests aus.

Wie es die "Goals" ausführt und wie Maven überhaupt alles macht, ist in der "parent pom" beschrieben. Sie gibt alle Default Werte vor. es ist eine pom.xml Datei im Maven Ordner.

Nun ist Maven so aufgebaut dass man mit einer weiteren pom.xml im Projektverzeichnis alle Standardwerte überschreiben kann - und auch bestimmte Pflichtwerte setzt (z.b. Projektname).


Nun kann man wie du schreibst beliebig viele pom.xml dazwischen haben:

• eine in <user>/.m2/settings.xml
• eine "parent.pom" im "parent projekt" - davon kann es beliebig viele geben

Speziell zur Frage:

Das Problem ist: Spring bringt eine sehr große mächtig parent mit - allein hier alle Abhängigkeiten im Blick zu haben ist schwierig.



Ich würde so wie mit alle Vorgaben vorgehen: Man gibt Empfehlungen ab. Ich würde den Teams Spring IO (Initilizr) zeigen und erklären. Und eventuell Beispiele geben.

Folgende Gefahr besteht wenn du funktionierende Vorlagen gibst: Sie werden einfach blind verwendet - meistens ohne Nachdenken. Probleme die darauf zurückzuführen sind werden dir dann angelastet. Das verwischt Verantwortlichkeiten - und das willst du vermeiden!
(Das gilt für alle "Vorgaben" - Das Projekt und Team trägt die Verantwortung sie umzusetzen oder eben nicht. Blind umsetzen ist immer falsch).

Hier zu deinen Argumenten:

• das Wissen hat nur die Person, wer den Parent macht

--> ein Argument gegen eine Parent pom - man versucht immer "single point of failure" zu vermeiden

• bei Updates (log4j) warten alle dann auf genau den

--> genau und das Team / Projekt kann die Verantwortung schön nach außen schieben, das will man nicht (zumindest nicht wenn man sowas wie "agiles" Arbeiten will)

• die Kollegen können sich zurücklehnen, denn irgendwelche Migrationen macht ja der, der das Wissen hat.

--> sie letztes Argument

• die Entwicklung eines Services dauert mit unter was länger

--> nicht sobald das Wissen mal breiter aufgestellt ist. insbesondere singt der Wartungsaufwand wenn das Team den eigenen Code kennt und versteht

• Updates muss jeder selber machen und auch migireren

--> dieses Wissen sollte überall vorhanden sein - insbesondere Sensibilität über Sicherheitlücken in Abhängigkeiten (da gibt es Tools für)

• Wissen dazu müssen alle aufbauen.

--> genau das will man - ein Wille Leben langes lernen sollte in allen Entwicklerköpfen sein - bzw. aufgebaut werden

 

[KeepCalm]

@dermoritz ... war ein Test, bestanden !!! Magst Du bei uns in der Firma anfangen genau so einen Entwickler kann ich noch als Counterpart gebrauchen !!!

Scherz beiseite ... Du hast das konkretisiert, was mein Bauchgefühl gesagt hat ... das gibt mir ein paar Argument, vielen Dank

 

[wahli]

Wieso darf nur einer das parent-pom-file anfassen?
Dort sollte das dependency management gemacht werden und alle Versionen der dependencies sollten dort zentral eingetragen werden.
Alle Submodule mit eigenem pom-file können diese dependencies verwenden und sollten keine Version angeben.
Wenn ein Entwickler eine neue dependency benötigt, muss er diese auch im parent-pom-file eintragen. Über die git-history ist ja ersichtlich, wer es war. Außerdem gibt es einen Gesamt-build inkl. Unittests, um festzustellen, dass noch alles funktioniert.
Wer die Framework-Upgrades macht, ist ein anderes Thema. Das sollten in der Regel erfahrene Leute machen. Derjenige muss natürlich schauen, dass anschließend alles funktioniert und die Tester müssen dann auch die Applikation(en) prüfen.
Z. B. renovate bots können auch selbstständig merge requests bei neueren Versionen von dependencies in gitlab anlegen. Wir verwenden das als Ausgangsbasis für die manuellen monatlichen Framework-Upgrades. Man sollte hier schon immer dran bleiben, damit die Upgrades nicht zu heftig werden. Aus Erfahrung kann ich nur sagen, wer nur einmal im Jahr upgraded, hat viel Aufwand und viele Probleme.

 

[KeepCalm]

diese Erfahrung kann ich nur teilen und bestätigen, ich habe ein internes Framework von SpringBoot 1.5 auf 2.0 gehoben und dafür mehrere Monate benötigt .. und nun .. es gibt Spring Boot 3.x und ich habe schon die weiße Fahne geschwenkt und gesagt, das ich das nicht mehr machen möchte ...
Die Reaktion war dazu eigentlich .. wir können es nicht und haben auch keine Zeit ..

 

[dermoritz]

@KeepCalm kannst mich gerne beauftragen - bin professioneller IT Berater (Telefonate oder so Erklärungen wie oben sind immer kostenlos)

einfach "dermoritz" googeln - Bildersuche, Der erste Treffer bin ich :-P. Dann hast mehr infos :-D.

Migration von Spring 2->3 ist nicht ganz so schlimm. Aber wenn man das dezentral hat - eben nicht in einer parent pom. kann und muss sich jedes Team darunm kümmern - und jedes Team kann den Zeitpunkt wählen
--> kein Big Bäng, alles schön iterativ. Die Erfahrung die man bei Projekt A macht fließt dann bei B und C ein - sehr hilfreich.

 

[wahli]

Ja, Spring Boot 1.5 auf 2 war auch schon ungemütlich. Kann ich bestätigen. Aber Monate? Das liegt dann eher an dir In einer Woche sollte das erledigt sein, auch für größere Projekte.

Ich muss auch bald ein paar Projekte von Spring Boot 2 auf 3 upgraden. Wir haben einige Vorarbeiten schon eingeplant, sonst wird man scheitern. Z. B. ging gestern Java 17 live. Jetzt stehen noch einige weitere Vorarbeiten an, z. B. alle dependencies mit javax austauschen. Ich verwende auch noch EHCache und da ist ziemlich sicher auch was zu tun. Da muss man sich gut informieren, was da alles zu tun ist.

Mein Kollege arbeitet gerade an der Umstellung Spring Boot 3 bei einem Großprojekt und kämpft gerade mit Soap. Wir sind natürlich immer dran, alte Technologien (z. B. Soap) durch neuere (REST) zu ersetzen, aber durch Abhängigkeiten mit anderen Firmen und auch interner Ressourcenknappheit geht das nicht immer schnell genug.

Bei uns gilt der Herbst als Deadline für die Umstellung von +100 Projekte auf Spring Boot 3. Durch die hohe Zahl an Projekten gibt es einen guten Erfahrungsaustausch zwischen den Projekten. Es muss also nicht jeder das Rad neu erfinden und schaut sich die Änderungen von anderen an.

 

[KeepCalm]

Bei der Migration von 2 nach 3 habe ich auch schon eine unangenehme Überraschung erlebt .. sämtliche Variablen im Actuator Endpoint sind ausgesternt ... nicht nur die, die passwort password, key oder secret enthalten, sondern alle ...

Ergänzung (17. Mai 2023)

und für REST kann ich nur den API-First Ansatz empfehlen mit openapi und dem Maven Plugin dazu ... kein Boilerplate mehr für Client / Server im wesentlichen braucht man nur noch Interfaces mit konkreten Funktionsnamen (ObjectId im openapi) implementieren .. alles andere wird generiert ..

Ergänzung (17. Mai 2023)

Ja, Spring Boot 1.5 auf 2 war auch schon ungemütlich. Kann ich bestätigen. Aber Monate? Das liegt dann eher an dir

zu meiner Verteidigung ...

• nicht nur Boot, sonder auch jede Menge Batch-Kram da drauf
• Parents über 3 Ebenen
• Einsatz von anderen Bibliotheken aus GIT-hub die auch noch nicht portiert waren aber natürlich überall eingesetzt .. da musste ich erst mal Merge-Requests machen
• falsch genutzte Autoconfiguration
• jede Menge Infrastructure Auto-Magic die auf einmal nicht mehr klappte und tatsächlich gibt es noch Elemente, die immer noch in der spring.factorier bleiben müssen ?!?!
• geändertes Default-Verhalten im Threading / Threadool ...

 

[dermoritz]

@KeepCalm das klingt nach dem ganz normalen Wahnsinn wenn man versucht alles auf einmal zu verbessern.
Z.b. würde ich bei Projekten <Java17 nie Spring Boot und Java gleichzeit upgraden.

So auch mit andere Dingen der technischen Schuld - eins nache dem anderen - "devide & conquer".
Wenn man dann noch ein gutes Test-Setup hat: Eine punkt der Liste machen testen, falls grün nächster schritt ansonsten role-back.
Je kleiner die Schritte desto besser.

 

[wahli]

Kann es sein, dass deine komplette Firma eine parent-pom für alle Projekte verwendet?

Ja, Batch verwende ich auch. Das hatte mit Spring Boot 2 schon einige Probleme gemacht. Daran erinnere ich mich gerade wieder. Ok, mal schauen wie es diesmal läuft.
Und actuator wundert mich ein wenig, weil es eigentlich Standard sein sollte. Hab noch von keinem Kollegen über Probleme gehört.
Ein geändertes Verhalten von Threading...hab Angst

Kurzes Update vom meinem Kollegen:
Soap blockiert jetzt nicht mehr, aber sämtliche Securitykonfigurationen sind jetzt deprecated. Und noch sehr viele andere Dinge sind anscheinend auch deprecated. Ich höre ihn gerade fluchen Sein aktueller Blocker ist Azure Servicebus und muss vermutlich komplett auf eine andere Dependency umgestellt werden. Ich verwende Azure Servicebus nur bei einem meiner Projekte und es wurde erst vor ca. einem Monat eingebaut unter Verwendung einer anderen Dependency (die hoffentlich mit Spring Boot 3 funktioniert).

@dermoritz
Ja, kleine Schritte sind da extrem wichtig. Deshalb wird bei uns schon seit den letzten 3 Monaten alles mögliche hochgezogen/ausgetauscht. Z. B. habe ich bei einem Projekt gestern Java 17 eingesetzt. Alleine für Java 17 sind schon einige Anpassungen notwendig.

 

[KeepCalm]

Kann es sein, dass deine komplette Firma eine parent-pom für alle Projekte verwendet?

Ja, das war der Fall und die Abteilung, die das gemacht hat wurde aufgelöst, alle anderen haben dann in die Röhre geschaut und ich habe das in unserem Bereich dann geupdated .. eine interessante Erfahrung

das geänderte Verhalten vom Actuacor Part ist hier beschrieben....
https://github.com/spring-projects/...Release-Notes#actuator-endpoints-sanitization

das heißt also man kann zwar WHEN_AUTHORIZED konfigurieren, dann wird aber auch alles angezeigt.
Lösung .. ein SanitizingFunction-Bean .. (wir setzen übrigens den SpringBootAdmin ein .. cooles Teil )

  @Bean
    public SanitizingFunction sanitizingFunction ( ) {
        return data -> ( data.getKey().toLowerCase().contains("passwort") ||
                           data.getKey().toLowerCase().contains("password") ||
                           data.getKey().toLowerCase().contains("key")      ||
                           data.getKey().toLowerCase().contains("secret")
                          )
                ? data.withValue(SanitizableData.SANITIZED_VALUE)
                : data;
    }

zum Threadingpool ..betrifft den TaskExecuter, man konnte vorher Blödsinn konfigurieren, als so was wie
max.pool.size < core.pool.size
was eigentlich keinen Sinn macht ... das gibt dann extrem komische Fehlermeldungen beim start.

Gruß an den Kollegen :-)

Ergänzung (17. Mai 2023)

wir driften echt ab ... und werden hier extrem nerdig ...

Ergänzung (17. Mai 2023)

und zu ständigen Updates .. DepandaBot ist schon im Einsatz und mit dem hier beschäftige ich mich dann in naher Zukunft .. OpenRewrite
... und endlich wieder mehr Zeit für Games

 

[DefconDev]

Ehrlich gesagt verstehe ich den Eingangspost immer noch nicht in Gänze.

Also ein Parent Pom ist jetzt keine Raketenwissenschaft, auch kein Hardcore Nerdwissen. Eigentlich ist es die POM die für alle Unterprojekte die kleinste Basis darstellt.
In der Android Programmierung ist das Beispielsweise unterteilt in eine Modul und Projekt build.gradle.

Und außer ein "paar" Abhängigkeiten zu definieren und grundlegende Sachen wie die Java Version und ähnliches musste ich bisher nichts machen was nur eine(r) aus dem Team kapiert. Habe selber erst letztens unsere Android App von 6 auf 13 gehoben(Android 13, intern mit 33). Und etliche Abhängigkeiten mussten auch hochgezogen werden, wie auch Anpassungen am Source Code, insbesondere dann wenn die Abhängigkeiten in der Majorversion gestiegen sind. Das hat mich knapp einen Monat gekostet, dass alles zu ändern und anschließend zu testen. In der Regel hangelt man sich dann durch eine Exception zur anderen durch und fixt es.

In unsere Spring Anwendung, die leider nicht Spring Boot verwendet, haben wir auch eine Parentpom und etliche Child-Poms für die jeweiligen Module, handelt sich aber trotzdem um eine monolithische Anwendung. Aber nichts davon ist so kompliziert, dass es nur einer kapiert bzw. das man sich erst Tage einarbeiten muss für.

Aber das scheint beim TE etwas andere zu laufen, daher meine Frage was steht denn alles in der Parentpom drin?

 

[KeepCalm]

Okay, diese Frage zeigt mir, das ich nicht die ganze Wahrheit erzählt habe, ich stecke da wohl zu tief drin.

Das ganze ist nicht nur eine Parent mit Depdendecies (wenn dem so wäre, bin ich bei Dir) sondern tatsächlich ehr zusätzlich noch ein eigenes Framework (multi Modul Project .. getarnt als Parent), was viel spezifisches SpringBoot/Batch Wissen entweder hinter Fassaden kapselt oder auch vieles eingenständig für den Anwender "errät" und konfiguriert.
Zusätzliche noch einige Maven-Plugins mit spezifischen Konfiguration die mit unter tricky sein können, z.B. ein RPM-Maven-Plugin oder irgendwelche "generator" - Plugins (XML,openapi) die für sich schon einiges an Doku und Konfigurationsparameter haben... .. wenn so etwas ein anderer macht, freut man sich.

Der Anwender braucht sich dann nun noch vorwiegend um fachlichen Code kümmern und kann diesen ganzen Magic-Spring-Boot Kram oder diese diversen Plugins komplett vernachlässigen

In etwas vergleichbar mit einem sogenanntem Starter von SpringBoot nur selbst gestrickt und kompliziert.... deswegen hat das auch gedauert, den ganzen Kram zu upgraden .. nicht nur eine POM sondern ein komplettes, selbstgetricktes (nicht von mir) Framework; das muss man das auch erst einmal alles verstehen.

Einer hat also viel Wissen da eingebracht, damit andere so gut wie gar nichts wissen müssen.

public void foo (Object workOn) {
    // schreibe hier den fachlichen Code
}

Vielen Dank für die ganzen Anregungen und Diskussionen, das hat mit den ein oderen Aspekt nahe gebracht, irgendwie ein unerschöpfliches Thema und verschiedene Philosphien von daher bertrachte ich das hier mal als erledigt .

Danke an alle

 

[DefconDev]

Das hört sich sehr abenteuerlich an. Also das liest sich aufwendiger als wenn jeder Entwickler ein paar Sachen von Hand machen würde. Also der Kostennutzen-Faktor müsste beleuchtet werden aber das kann ich null beurteilen ohne die Details zu kennen.

Die Frage wäre für mich, wie abhängig macht sich dein Chef von dir. Mit sowas würde ich immer in Gehaltsverhandlungen gehen ohne natürlich erpressierich zu wirken.

 

[wahli]

Wir hatten auch mal eine zentrale parent-pom für die ganze Firma (die nicht von allen verwendet wurde), aber vor ca. 5 Jahren wurde das aufgegeben. Es gab auch diverse Firmen-dependencies, aber auch diese werden eigentlich kaum noch genutzt. Ich habe die letzten Reste jetzt endlich in meinem Applikations ausbauen können. Die müssen ja auch gepflegt werden und da gab es immer wieder Probleme (wer, wann, Budget, Kompatibilität,...).
Unabhängigkeit ist bei uns mittlerweile sehr wichtig. Sogar bei Schnittstellen werden die Übertragungs-Objekte selbst verwaltet, d. h. es werden keine API-dependencies von den anderen Projekten eingezogen.

Bei meinen Projekten ist die parent-pom nur ein dummer Container mit Versions-properties, dependencyManagement und pluginManagement. Richtige plugins sind nur ganz zentrale plugins wie maven-javadoc-plugin und maven-compiler-plugin.
In den sub-poms sind dann aber auch mit "magic" befüllt. Der ganze Frontendkram, OpenAPI, generatoren, usw. unterstützen hier massiv bei der Entwicklung. Auch bei uns kennen sich natürlich nicht alle damit aus, aber doch einige. Da muss man einfach Knowhow aufbauen und auch dokumentieren.