Java Dependencies auslesen

[Java Rumnicht]

Guten Tag liebe Java-Forum Gemeinde .

Ich habe ein Probl...nein, eine Herausforderung:


Mein Ziel ist es innerhalb einer Multiprojekt-Umgebung eine Java Anwendung zu entwickeln, die die direkte und transitive Abhängigkeiten von Projekten anzeigen kann.

Meine erste Überlegung war, ganz simple die pom's zu Parsen. Ich bekam jedoch den Hinweis, dass das mit Sicherheit besser geht.
In vielen Quellen habe ich Codeschnipsel gesehen, die in Java Klassen 'einfach' auf Projektinformationen zugreifen.
Beispiele: projektname.getGroupId(), .getArtifact() usw.

Doch wie kann ich das umsetzen? Wie kann ich so direkt in die Maven Bibliothekt zugreifen, ohne die Projektmodelle zu parsen?


Ich hoffe ihr versteht meine wirren Worte .

Vielen Dank für jede Bemühung im Voraus!

 

[Noctarius]

Schau dir mal Aether an, das ist der Dependency Resolver in Maven (Aether)

 

[kama]

Hi,

ein

mvn dependency:tree

reicht Dir nicht?

Schau Dir auch mal das hier an:

https://github.com/khmarbaise/pom-interpolator-test


Gruß
Karl-Heinz Marbaise

 

[Java Rumnicht]

Vielen Dank für die schnellen Antworten.

Das Video kann ich leider erst heute Abend anschauen, die sind hier leider gesperrt .

Ansonsten: Ja, ich denke das würde mein Problem in seinen Ansätzen lösen, ABER ich hatte gehofft auf den Einsatz eben solcher Plug-Ins verzichten zu können.

Lässt sich denn nicht händisch auf die Abhängigkeiten zugreifen?

ein


Code:
mvn dependency:treereicht Dir nicht?

Ich befürchte nicht. Ziel ist es die Abhängigkeiten über eine Java Anwendung auch innerhalb der Anwendung anzeigen zu lassen (und ggf. speichern zu können in einer Datenbank).

Meine 'Aufgabe' ist es (ich hoffe ich zitiere soweit richtig), auf die "Schnittstelle in Maven" zuzugreifen, die auch die Poms mit Daten versorgt, und über diese die Dependencies direkt aus der Maven Bibliothek in der Anwendung aufzurufen.

 

[Sym]

Da sich die Bibliotheken nicht zur Laufzeit ändern, hast Du die Dependencies (z.B. durch mvn dependency:tree) doch vorliegen. Diese kannst Du dann als Bild in eine DB oder als File in oder neben das Jar legen. Und wenn es immer mit ausgeliefert werden soll, bau Dir ein Maven-Plugin, welches beim Release (oder package oder oder oder) dies mit generiert.

Wofür werden diese Informationen denn benötigt?

 

[Java Rumnicht]

Da sich die Bibliotheken nicht zur Laufzeit ändern,

Ist in dieser Multiprojektumgebung hier leider doch der Fall.

Die Informationen sollen schlicht weg nur grafisch an der Oberfläche dargestellt werden.

Es muss doch einen Weg geben zur Laufzeit die Dependencies auszulesen? :/

 

[kama]

Hallo,

Es muss doch einen Weg geben zur Laufzeit die Dependencies auszulesen? :/

Welche Abhängigkeiten ändern sich zur Laufzeit?

Warum auch immer....wenn aber ja, dann ist Maven der Falsche Weg!

Weiterhin kann man mit dem maven-dependency-plugin die Infos schon in eine Datei schreiben:

mvn dependency:tree -DoutputFile=tree.out

also einfach per execution in den lifecycle und das entstandene File später irgendwo mit verpacken...


Gruß
Karl-Heinz Marbaise

 

[Sym]

Ist in dieser Multiprojektumgebung hier leider doch der Fall.

Die Informationen sollen schlicht weg nur grafisch an der Oberfläche dargestellt werden.

Es muss doch einen Weg geben zur Laufzeit die Dependencies auszulesen? :/

Da würde mich interessieren, wie das geht und was der Grund dahinter ist.

 

[Noctarius]

Weil z.B. nicht alle Module deployed werden. Ergo kann man aber per Maven Dependencies alle Abhängigkeiten auflösen lassen bzw prüfen ob alles passt.

 

[Sym]

Weil z.B. nicht alle Module deployed werden. Ergo kann man aber per Maven Dependencies alle Abhängigkeiten auflösen lassen bzw prüfen ob alles passt.

Du meinst, dass zur Laufzeit andere Module deployed werden könnten, die den Dependency-Stack erhöhen? Beim Nachdeployen von Modulen kennt man doch ebenfalls die Dependencies und könnte diese direkt mitpflegen.

 

[Noctarius]

Denke an Features einer Application, welche z.B. durch Lizenzen freigeschaltet werden. Du willst aber keine Features mitladen (z.B. in einer OSGi Umgebung) die nicht lizensiert sind. Also musst du den Dependency Tree zur Laufzeit auflösen und entsprechende Abhängigkeiten verdichten und laden. Wenn der Kunde nun seine Lizenz erhöht wird beim nächsten Start auf mehr geladen.

Solche Abhängigkeitenverwaltungen bekommst du in Maven geschenkt, wofür zusätzlich pflegen?

Es gibt also durchaus Anwendungsfälle wo sich eine bereits deployed Anwendung im Umfang ändern kann.

 

[Sym]

Das es Sinn haben kann, Module nachzuladen, ist mir klar. Allerdings kann ich vom Server erfragen, welche Module geladen sind. Die Module selbst haben feste Dependencies und Linken keine zur Laufzeit hinzu. Beim Erstellen der Module sind also die Dependencies klar. Warum etwas zur Laufzeit berechnen, dass zur Compilezeit bekannt ist?

 

[Java Rumnicht]

Ich war auch überrascht, dass sie sich zur Laufzeit ändern, aber hab auch explizit bestätigt bekommen, dass es so ist.

Okay, um euch mal den Anwendungsfall näher zu beschreiben:
In dieser Umgebung befinden sich ca. 10 Anwendungen. Zwei Studenten haben mal die Aufgabe bekommen eine Anwendung zu entwickeln, die alle möglichen Informationen darstellt, u.A. Abhängigkeiten der Anwendung.
Da man diese aber alle per Hand eintragen muss, wäre das bei jeder aktualisierung ein tagelanger Aufwand die zu warten, ist also quatsch.

Deshalb hatte ich die Überlegung ob es nicht möglich wäre, für jedes Projekt nicht alle Daten, sondern einfach nur den SVN Pfad zum Super-POM anzugeben. Dieses enthält ja genug Daten um auf andere Inhalte zu verweisen, die dann die Abhängigkeiten beinhalten.

Denkt ihr das funktioniert nicht?

 

[kama]

Hallo,

Deshalb hatte ich die Überlegung ob es nicht möglich wäre, für jedes Projekt nicht alle Daten, sondern einfach nur den SVN Pfad zum Super-POM anzugeben. Dieses enthält ja genug Daten um auf andere Inhalte zu verweisen, die dann die Abhängigkeiten beinhalten.

Denkt ihr das funktioniert nicht?

Warum denn nicht...Anhand der POM kann ich alles holen...alle Abhängigkeiten zu anderen Projekten etc. Hier wäre aber noch die Frage ob man nur die Release Versions macht oder auch die SNAPSHOT's ...

Weiterhin beschreibt die POM ja die statischen Abhängigkeiten und somit beschreibt es nicht Module die zur Build Zeit benötigt werden aber dann eventuelle im Server nicht geladen werden...

Weiterhin ist es wichtig hierbei zwischen den unterschiedlichen Scopes zu unterscheiden... (compile, test, provided, runtime etc.).

In Ähnlicher Form habe ich so was schon mal gemacht...und als Graphviz aufbereitet...

Da kommen mir so Sachen Neo4J in den Sinn....da könnte man dann auch eine Analyse Fahren...

Gruß
Karl-Heinz Marbaise

 

[Noctarius]

Das es Sinn haben kann, Module nachzuladen, ist mir klar. Allerdings kann ich vom Server erfragen, welche Module geladen sind. Die Module selbst haben feste Dependencies und Linken keine zur Laufzeit hinzu. Beim Erstellen der Module sind also die Dependencies klar. Warum etwas zur Laufzeit berechnen, dass zur Compilezeit bekannt ist?

Natürlich ändern sich die Abhängigkeiten zur Laufzeit nicht aber wofür Daten verdoppeln? Die pom.xml liegt doch eh bereits in den JARs, warum sollte ich die Daten dann noch mal irgendwo hinterlegen?

 

[Java Rumnicht]

Ich danke euch schon mal für alle weiteren Antworten, ich grase nebenbei alle Vorschläge von oben ab.

Ich denke ich hab selbst auch eine Lösung gefunden. Sollte diese funktionnieren, werde ich sie hier natürlich posten.

 

[Sym]

Natürlich ändern sich die Abhängigkeiten zur Laufzeit nicht aber wofür Daten verdoppeln? Die pom.xml liegt doch eh bereits in den JARs, warum sollte ich die Daten dann noch mal irgendwo hinterlegen?

Der dependency-tree ich besteht ja nicht nur aus der ersten Hierarchy. Wenn natürlich nur diese wichtig ist, geht es auch ohne.

 

[Noctarius]

Aether ist der Dependecy Traversal Mechanismus in Maven selber und kann auch extern genutzt werden, ich verstehe deinen Punkt nicht.

 

[Sym]

Ich verstehe nicht, warum man so etwas statisches zur Laufzeit bestimmen sollte.

 

[Noctarius]

Ich verstehe nicht wieso sollte ich Daten, welche ich ja auch durch ein spezielles Maven Plugin aufarbeiten müsste (alternativ pflege ich selber irgendeine Definitionsdatei - z.B. in XML) hinterlegen sollte wenn ich das Dependency Management von Maven geschenkt bekomme.