Maven Auflösung von transitiven Abhängigkeiten

[xhi2018]

Hallo,

ich versuche mein Java Projekt

de.my.javaprj:foo-bar

über maven zu bauen, dass über transitive Abhängigkeit

log4j:log4j:jar:1.2.15

benötigt und deshalb auch

javax.jms:jms:jar:1.1

benötigt. So verstehe ich zumindest die Ausgabe im Debug-Modus:

[DEBUG] de.my.javaprj:foo-bar:jar:0.0.1-SNAPSHOT
[DEBUG]    com.caucho:hessian:jar:3.2.1:compile
[DEBUG]    de.my.javaprj:foo-base:jar:1.00-00-SNAPSHOT:compile
...
[DEBUG]       com.ibm.mq:com.ibm.mq:jar:6.0.2.0:compile
[DEBUG]       log4j:log4j:jar:1.2.15:compile
[DEBUG]          javax.mail:mail:jar:1.4:compile
[DEBUG]             javax.activation:activation:jar:1.1:compile
[DEBUG]          javax.jms:jms:jar:1.1:compile
[DEBUG]          com.sun.jdmk:jmxtools:jar:1.2.1:compile
[DEBUG]          com.sun.jmx:jmxri:jar:1.2.1:compile
[DEBUG]       coherence:coherence:jar:3.5.3p8:compile

Das Projekt bekomme ich nicht gebaut, weil maven die Abhängigkeit zu

javax.jms:jms:jar:1.1

nicht besorgen/auflösen kann.

mavenExecutionResult exceptions not empty
message : Failed to execute goal on project commons-facility-api: 
Could not resolve dependencies for project de.my.javaprj:foo-bar:jar:0.0.1-SNAPSHOT: 
The following artifacts could not be resolved: 
javax.jms:jms:jar:1.1, com.sun.jdmk:jmxtools:jar:1.2.1, com.sun.jmx:jmxri:jar:1.2.1: 
Could not transfer artifact javax.jms:jms:jar:1.1 from/to java.net 
(https://maven-repository.dev.java.net/nonav/repository): 
No connector available to access repository java.net 
(https://maven-repository.dev.java.net/nonav/repository) of type legacy using 
the available factories WagonRepositoryConnectorFactory

So verstehe ich auf jeden Fall die Fehlermeldungen.
Als Lösung des Problems finde ich entweder

log4j

in den dependencies der pom.xml von

de.my.javaprj:foo-bar:jar:0.0.1-SNAPSHOT

zu excluden oder aber

log4j:log4j:jar:1.2.14

zu verwenden, weil in dieser Version noch keine Abhängigkeit zu

javax.jms:jms:jar:1.1

besteht.
maven2-log4j-and-jmx-dependencies
resolving-log4j-1215-dependency-problems-in-maven-using-exclusions

Ist so was der normale "maven"-Weg oder wie werden sonst solche Probleme gelöst ???:L Lustigerweise kann ich das Projekt in Eclipse über "Run As.." -> "Maven Build" fehlerfrei bauen. Die Debugausgabe sieht in der Eclipse Console so aus:

[DEBUG] de.my.javaprj:foo-bar:jar:0.0.1-SNAPSHOT
[DEBUG]    com.caucho:hessian:jar:3.2.1:compile
[DEBUG]    de.my.javaprj:foo-base:jar:1.00-00-SNAPSHOT:compile
...
[DEBUG]       com.ibm.mq:com.ibm.mq:jar:6.0.2.0:compile
[DEBUG]       log4j:log4j:jar:1.2.15:compile
[DEBUG]       coherence:coherence:jar:3.5.3p8:compile

In diesem Fall werden die transitiven Abhängigkeiten von

log4j:log4j:jar:1.2.15

von maven offensichtlich nicht berücksichtigt.Wie ist so was zu erklären..?:autsch:
In Beiden Fällen wird die selbe Maven Version verwendet:

Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
...
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows vista", version: "6.0", arch: "x86", family: "windows"...

Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
....
Default locale: de_DE, platform encoding: ISO-8859-15
OS name: "linux", version: "2.6.16.60-0.89.1-smp", arch: "i386", family: "unix"

Gruß & vielen Dank für die Hilfe!

 

[maki]

Ist so was der normale "maven"-Weg oder wie werden sonst solche Probleme gelöst

Ja, das sind die beiden Alternativen wenn Leute ihre Poms nicht sauber halten, wie in diesem Falle die Log4J "Leute":
Maven doesn?t suck, your POM does | Javalobby

 

[xhi2018]

Ja, das sind die beiden Alternativen wenn Leute ihre Poms nicht sauber halten, wie in diesem Falle die Log4J "Leute":
Maven doesn?t suck, your POM does | Javalobby

danke für die schnelle Antwort..
Eine von mir nicht steuerbare Abhängigkeit führt also dazu, dass keines meiner Projekte mehr gebaut werden kann und ich dann unter Umständen zig pom.xml's meiner Java Projekte anzupassen hab...
Frage an die Experten:
Funktioniert maven wirklich so..?
Und kann sich jemand erklären warum das in Eclipse nicht so ist?

vielen Dank!

 

[nillehammer]

Ich glaube, die Idee von den log4j-Jungs war die Unterstützung exotischer logging-Varianten und nicht nur in Dateien. Das blöde ist nur, dass mail und jmx nicht im central Repo verfügbar sind, sondern in extra Repositories liegen (ich glaub java.net oder so). Das scheinen die von Log4j aber auch direkt gemerkt zu haben. Ab Version 1.2.16 ist die Dependency nicht mehr drinnen.

Funktioniert maven wirklich so..?

Ja, die Auflösung transitiver Abhängigkeiten ist ein mächtiges Feature von Maven, das einem ne Menge Arbeit spart. Sie ist aber auch anfällig für Fehler und deswegen auch einer der Hauptkritikpunkte an Maven.

Und kann sich jemand erklären warum das in Eclipse nicht so ist?

Warum sich das Eclipse-Plugin daran nicht verschluckt hat, kann ich nur vermuten. Vielleicht ist es etwas schlauer und hat über irgend ein Repoository, das das Kommandozeilenprogramm nicht abfragt, die Dependency auflösen können

 

[maki]

Eine von mir nicht steuerbare Abhängigkeit führt also dazu, dass keines meiner Projekte mehr gebaut werden kann und ich dann unter Umständen zig pom.xml's meiner Java Projekte anzupassen hab...

Natürlich kannst du die transitiven Abhängigkeiten steuern, zB. mit [c]<exclude>[/c].
Was soll man denn anderes machen können wenn die Urheber die Pom verpfuscht haben?
Ausser natürlich das Artifact mit einer angepassten Pom in seinen lokalen repo manager hochzuladen... aber ob das besser ist? Glaube nciht!

Ich glaube, die Idee von den log4j-Jungs war die Unterstützung exotischer logging-Varianten und nicht nur in Dateien. Das blöde ist nur, dass mail und jmx nicht im central Repo verfügbar sind, sondern in extra Repositories liegen (ich glaub java.net oder so). Das scheinen die von Log4j aber auch direkt gemerkt zu haben. Ab Version 1.2.16 ist die Dependency nicht mehr drinnen.

Die Log4J Jungs haben leider nicht gewusst was es mit [c]<optional>true</optional>[/c] auf sich hatte

 

[mvitz]

Naja und bei 1.2.16 haben sie dann zwar diese Dependencies glatt gezogen, dafür aber das packaging auf bundle gestellt (was für meinen IVY Build ein wenig Zeit gekostet hat, bis ich das gefunden hatte).