Mehrere gleiche Jars im Classpath

[Tarantoga]

Liebe Community!

Für ein Web Projekt verwende ich Spring und Maven. Für den File-Upload benötigt man das commons-fileupload.jar.

Leider bekomme ich beim Upload eines Files immer einen NoSuchMethodError. Habe mittlerweile auch herausgefunden, dass das Problem darin liegt, dass sowohl commons-fileupload1.0 als auch die 1.1 Version auf dem Classpath liegen.

Da 1.0 immer zuerst aufgerufen wird entsteht der Error.
Nachdem ich nun die Dependencies aus dem pom-file entfernt habe wurden aus den ursprünglich 3 jars, die oben genannten zwei.

Explizit referenziere ich jetzt nirgends mehr auf die Jars, aber sie tauchen trotzdem immer wieder in der lib auf.
Ich vermute also, dass sie entweder im zuge von anderen Dependencies (zb. Spring, ..) heruntergeladen werden, oder von außerhalb bei jedem Clean&Build hinzugefügt werden.
Habe gelesen, dass der Glassfish Server so etwas tut.

Meine Frage also:
Wie kann ich verhindern, dass ohne meinen Willen verschiedene Versionen von commons-fileupload auftauchen?
Ich möchte einfach die Dependency in der pom haben und aus.
Also alle anderen möglichen Quellen killen, oder zumindest irgendwie rausfinden, wer oder was andauernd meinen Classpath zumüllt.

LG

 

[javabar]

Ich würde was probieren, aber ich weiss nicht ob es hilft:

commons-fileupload1.0.jar woanders hin verschieben. (wenn's nicht gebraucht wird, sondern 1.1)

Dann erstellst Du ein leeres jar, das keine Klassen enthält, und nennst es commons-fileupload1.0.jar, und legst es in den Ordner mit den anderen Jars.

Ist zwar keine saubere Lösung, aber es kann evtl. funktionieren, es sollte auf die Klassen vom 1.1 dann zugreifen. Wenn's nicht klappt, kann's sein die 1.0 wird woanders benötigt, dann hast du ein echtes Problem, wenn zwei verschiedene Versionen gleichzeitig benötigt werden.

 

[Marcinek]

Afaik wird das nicht klappen.

Er nutzt Artefakte, die 1.0 als Dep haben und Artefakte, die 1.1 als Deps haben.

Ich kenne mich mit Maven nicht 100 % aus, aber ich glaube er muss die unnötigen Artefakte "excluden" in der Pom.

 

[kama]

Hi,

mal ein

mvn dependency:tree

auf Dein Projekt ausführen, dann solltest Du sehen woher die einzelnen Dependencies kommen...
Ausschluss von dependencies eben mit vorgeschlagener Vorgehensweise...excludes...

Gruß
Karl-Heinz Marbaise

 

[caleb]

Und hier wie diese exclusion funktioniert[XML]
<dependency>
<groupId>a.b</groupId>
<artifactId>lib.mit.abhängigkeit.zu.fileupload1.0</artifactId>
<version>x.x</version>
<exclusions>
<!-- eine oder mehrere exclusion -->
<exclusion>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
</exclusion>
</exclusions>
</dependency>[/XML]

Die schuldige Lib wie im vorhergehenden Post erwähnt mit dependency:tree suchen.

Alternativ (und als instabile und schlechtere Lösung anzusehen) kannst Du die Reihenfolge der Abhängigkeiten im Pom umstellen. D.h. die Abhängigkeit zu der Version 1.1 muss vor der Abhängigkeit mit der Version 1.0 kommen. Maven würde in diesem Fall dann nur die Fileupload Library mit der Version 1.1 ins War kopieren.
Das die Reihenfolge aber garantiert wird von Maven steht meines Wissens nirgends garantiert, deswegen nimm doch die Lösung mit den Exclusions.

 

[maki]

Das die Reihenfolge aber garantiert wird von Maven steht meines Wissens nirgends garantiert, deswegen nimm doch die Lösung mit den Exclusions.

Doch, natürlich, seit Maven 2.0.10: [#MNG-3424] Respect ordering of elements as given in POM - jira.codehaus.org

Ansosnten empfehle ich noch das depdencyManagement Element, damit kann man Versionen von dependencies festlegen.

 

[Tarantoga]

Danke für eure Antworten!
Ich habe aus der Struts-Bibliothek commons-fileupload excluded und commons-fileupload1.0 aus der glassfish lib überhaupt entfernt. Ich weiß, das ist eher nicht so gut, aber ich konnte die Dependency einfach nicht finden.. Kann es sein, dass sie gar nicht von maven gemanaged wird?

Jedenfalls funktioniert es jetzt. Vielen Dank euch allen!

LG

 

[caleb]

Wenn es wirklich die Version im Glassfish lib war, die Ärger bereitet hast, kannst du auch im sun-web.xml den Classloader auf <delegate>false</delegate> setzen.
Das bewirkt, dass zuerst die mitgelieferten Libraries vom Classloader berücksichtig werden und erst im zweiten und dritten Schritt diejenigen der Domain und der Glassfish Installation.