Maven-Abhängigkeiten im Build prüfen?

[LimDul]

Ich stehe jetzt vor der Herausforderung, die Entwicklung für ein größeres Projekt zu organisieren (in der Vollausbaustufe ca. 40 verschiedene Anwendungen, die als Docker-Container in die Cloud deployed werden). Wir reden hier über Anwendungen die teilweise nahe an einem Monolithen sind, aber auch von Anwendungen die wirklich ein simpler Mikro-Service sind und die ganze Bandbreite dazwischen. Alles Spring Boot & Maven

Eine Sache, die ich dabei sicherstellen will, dass diese Anwendungen entkoppelt bleiben. Ich will vermeiden, dass Anwendung A eine Dependency auf einen Business-Teil von Anwendung B hat. Anwendungen dürfen nur das externe DTO-Modell der anderen Anwendungen referenzieren. Es hindert aber niemand einen Entwickler eine solche böse Dependency in die POM einzutragen, ich hab im Laufe der Zeit immer wieder erlebt, dass Dependency ergänzt wurden, die nicht hätten sein dürfen. In den meisten Fällen harmlos, aber hier kommen ein paar Aspekte dazu insbesondere auch die Projektlaufzeit (5 Jahre Entwicklung, 10+ Betrieb & Wartung). Daher will ich das automatisiert prüfen.

Archunit kann - soweit ich das sehe - nur auf Package Ebene checken. Das ist mir zu schwierig, auch wenn ich die Packages normalisieren will. Gibt es Möglichkeiten - ich denke da ein Jenkins Plugin - dem ich Richtlinien hinterlegen kann bzgl. verbotener Maven-Dependencys? So dass dann der Build failed?

 

[mihe7]

Meinst Du so etwas?

Banned Dependencies – Apache Maven Enforcer Built-In Rules

 

[LimDul]

Jepp, genau das. Jetzt wo ich lese, stelle ich fest, hab ich den Namen auch schon mal gehört. Aber find das mal mit Google wenn du was mit maven dependency check suchst 😀


Es macht mit dem Handling von includes/excludes es auch genau so, wie ich es vermutlich danke. Komplette group-ids bannen und dann einzelne Artefact-IDs rausnehmen. Jetzt bleibt nur die spannende Frage, wie ich verhindere, dass ein Entwickler an der POM rumpfuscht 🙂 aber an dem Teil wird man eher selten brangehen, während eine Dependency ja mal schnell ergänzt ist, ggf. macht das die IDE ja sogar fast unsichtbar im Hintergrund

 

[khmarbaise]

Meine Idee wäre sowas wie JQAssistant... https://github.com/jqassistant

 

[LimDul]

Meine Idee wäre sowas wie JQAssistant... https://github.com/jqassistant

Was kann das besser, dafür es gefühlt exponentiell komplexer aussieht? Ich finde da jetzt nicht, wie Maven Abhängigkeiten prüfen kann? Alleine transitive Dependencys sehe ich da nicht, dass ich mal eben prüfen kann.

Das sieht für mich auf den ersten Blick wie mit Kanonen auf Spatzen geschossen aus und führt zu einem weiteren Tool mit einer weiteren, nicht trivialen Syntax, wofür Wissen vorgehalten werden muss. Das Tool sieht nicht schlecht aus - aber für das was ich brauche ist es schlicht zu aufwendig und damit zu teuer nach meinem dafürhalten.

 

[richtig]

Schreib dir doch einfach ein Script dafür.

Jetzt bleibt nur die spannende Frage, wie ich verhindere, dass ein Entwickler an der POM rumpfuscht

Ich verstehe dich nicht ganz. Die POM(s) verwalten die Dependencies, und macht ihr keine Reviews der Code-Owner?

 

[KonradN]

Nur mal so als dumme Idee: Ist es evtl. eine Idee, dass man ein eigenes Repository aufsetzt?

Klar, Entwickler greifen ggf. weiter auf Maven Central zu oder so, aber die Build Server dürften ja nicht in der Hand der Entwickler sein. Da könnte man dann ein entsprechenden Mirror vorgeben.

Dann steuert man nur noch den Mirror. Eine Dependency, die nicht freigegeben wurde, steht dann nicht zur Verfügung.

Wobei das auch nicht zu 100% stimmt. Man kann dann immer noch ein lokales Repository angeben, das dann mit in der Source Verwaltung ist wo Entwickler beliebige Dinge mit hinein packen ...Aber da dürfte klar sein, dass hier Security der Firma klar umgangen wird....

Das nur als kleine Idee. Das ist halt, was ich auch kenne in diversen Ausführungen bei diversen Firmen.

 

[LimDul]

Eigenes Repo geht nicht. Was tiefer ins Detail, ich hab zwei Anwendungen A und B, beide liegen im gleichen GIT & gleichen Maven Repository.

Beide bestehen aus Modulen "domain", "business", "web" und "extapi".

Anwendung A darf logischerweise ihre eigenen Module referenzieren und das Modul extapi vom Anwendung B - aber keine anderen Module von Anwendung B. Und das sollte so wie ich das sehe mit dem enforcer Plugin simpel sein

 

[LimDul]

Schreib dir doch einfach ein Script dafür.

Warum, wenn das Maven Plugin genau das leistet?

Ich verstehe dich nicht ganz. Die POM(s) verwalten die Dependencies, und macht ihr keine Reviews der Code-Owner?

Auch wenn ich mir nicht sicher bin, wie sinnvoll die Antwort für dich ist, für andere kann es vielleicht erhellend sein. Wir reden hier über Software, deren Betrieb unter anderem unter DORA fällt und wo Fehler in Produktion schnell echt teuer werden können. Natürlich gibt es Code Reviews und natürlich gibt es Guildelines, das man sowas nicht macht. Aber auch beim Autofahren gibt es Regeln die einen Unfall verhindern sollen. Und auch da gibt es zig Absicherungen (Airbag, Notbrems-Assistenten, Sicherheitsgurt etc.). Daher sind zusätzliche, automatisch geprüfte Regeln selten verkehrt (Man muss immer Kosten/Nutzen abwägen). Aber die Implementierung wird vermutlich weniger als eine Woche dauern und wenn damit in den nächsten 15 Jahren auch nur ein Produktionsfehler vermieden wird, hat es sich schon gerechmet.

 

[Ebi]

Ich würde das nicht auf der Ebene von Maven machen, sondern entweder dafür das java module system verwenden, oder Archunit verwenden. Mein Argument dafür wäre, dass besser ist, solche Regeln klar im Code zu formulieren, als implizit über die POM. Aber wahrscheinlich ist das Geschmackssache