Bibliothekkonflikte in WebApps
Author: mstaender
Publication Date: 1/5/2017 8:56
Hi,
ich habe meinem Modul einen Button im ContentCreatoor gegönnt und dazu eine WebApp erstellt.
Hier tritt beim Ausführen meines Codes nun eine "NoSuchElementException" auf die mich zu dem Schluss drängte, dass ein Versionskonflikt vorliegt und siehe da: als ich in em Lib-Verzeichnis von Jetty nachsah fand ich dort unter anderem "commons-io-1.3.2.jar" welche Anfang 2008 released und im gleichen Monat schon durch Version 1.4 ersetzt wurde.
Die Bibliothek wird durch FirstSpirit deployed, ich verwende diese in keiner Bibliothek und in keiner Abhängigkeit und sie wird nicht von mir ins Modul gepackt, ich habe mir meine Dateien genau angesehen.
Ich nutze Version 2.5 und möchte nicht wirklich zurückportieren.
Wie kann ich hier vorgehen um mit möglichst wenig Aufwand die aktuelle Version zu nutzen?
MfG Marcus
Tags: api, contentcreator, fs5.2, web_application, webapp, webappclassloader
-
Author: thmarx - 1/5/2017 9:02
Hallo Marcus,
das ist leider ein bekanntest Problem für das es aktuell keine schöne Lösung gibt. Ich denke die schnellste Möglichkeit wäre es, wenn du deine Bibliotheken repackagest (https://maven.apache.org/plugins/maven-shade-plugin/), dass kannst du in deinen Build-Prozess einbauen.
Das Problem wird mit dem isolated Modus für Resouren etwas besser. Im ContentCreator wird es aber weiterhin das Problem geben, dass wenn zwei Module die gleiche Abhängigkeit in unterschiedlichen Versionen benötigen, es zu Konflikten kommen wird.
Gruß
Thorsten
0 -
Author: mstaender - 1/5/2017 9:07
Hi Thorsten,
danke erst einmal, das hatte ich befürchtet.
Habt Ihr zufällig ein Beispiel-Build-Script mit dem ich etwas schneller starten kann als bei 0 anzufangen?
Was empfehlt Ihr da genau zu machen? Müsste ich apache-io dann wirklich package-renamen (klingt am logischsten aber noch kann ich mir das schwer vorstellen) oder würde ich die Abhängigkeit in meine Bibliothek als "uber-jar" reinmergen?
Also hier wäre eine Beispiel-build.xml echt cool :smileyhappy:
MfG Marcus
0 -
Author: mstaender - 1/5/2017 10:32
Hi,
nachdem ich jetzt mit dem Shade-Plugin gespielt habe und zunächst eine 60 MB Monster-Uber-Jar gebaut habe (das Skript hat zunächst erstmal die fs-access.jar, fs-client.jar usw. mit einbezogen) und dann mit Excludes rumgespielt habe habe ich rausgefunden, dass die verendung von Includes alles andere außschließt, zumindest wird jetzt NICHTS außer die "geshadede" commons-io version mit ins JAR gepackt:
<!-- Rename commons-io to avoid problems with outdated firstspirit libs -->
<plugin><groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<!--<minimizeJar>true</minimizeJar>-->
<relocations><relocation>
<pattern>org.apache.commons.io</pattern>
<shadedPattern>org.apache.commons.io.fs</shadedPattern>
</relocation>
</relocations>
<artifactSet>
<includes>
<include>commons-io</include>
</includes>
</artifactSet>
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/license/**</exclude>
<exclude>META-INF/*</exclude>
<exclude>META-INF/maven/**</exclude>
<exclude>LICENSE</exclude>
<exclude>NOTICE</exclude>
<exclude>/*.txt</exclude>
</excludes>
</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>
Die Filter kann man noch entfernen aber da ich zunächst zu viel hatte und experimentiert hatte habe ich sie für andere als Beispiel mal drin gelassen.
MfG Marcus
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
3 Kommentare