Uber-Jar - Warum?

[Cakmakli-a]

Warum wurde entschieden aus der "Library" eine Uber-Jar zu machen?
Ich sehe darin nur Probleme. Z.B. Versionskonflikte.
Ist ein durchdachtest Dependency-Management nicht mehr möglich!?

[jstaerk]

Der Grund für die Änderung des primären Deployment war, war erstens, dass niemand dagegen gestimmt hat (https://groups.google.com/g/zugferd/c/Riml-eJmH70), es zweitens für den Menschen der den ursprünglichen PR eingebracht hatte OK war (#219) und ich es drittens ansonsten nicht hingekriegt habe die CII zu UBL-Umwandlung in der JAR der CLI zum laufen zu bringen. Außerdem ist bin ich mir viertens nicht sicher, ob das ungeshadete JAR nicht auch auf maven central wandert und per Classifier zur Verfügung steht.
Falls es dafür eine bessere Möglichkeit gibt: immer raus damit, sprich gerne PR.

[Andreas-LBC]

Hallo Jochen,

ich bin ein Kollege von Cakmakli-a und wir versuchen, ein möglichst dediziertes Setup in einer RedHat EAP Serveranwendung umzusetzen.
Ich denke, es wäre schon gut, ein entsprechendes Artifact bereitzustellen, idealerweise als BOM. So könnten wir uns ein Mustang Single Deployment und den dann bekannten Abhängigkeiten mit entsprechender Versionen selbst zusammen konfigurieren; zum Teil sind gängige Module / Dependencies bereits im JBoss Ökosystem vorhanden.
Ich denke auch, dass mit diesen Informationen andere Entwickler und Architekten mehr anfangen könnten.
Wir bitten Dich im ersten Schritt um die Unterstützung, alle Artifacts in Version zu nennen und eine SingleDistribution der Mustang Jar bereitzustellen. Idealerweise auch in Java 8 kompiliert.

Beste Grüße,
Andreas

[jstaerk]

Einen entsprechenden PR würde ich sehr begrüßen, wie gesagt seid bitte nur so nett und testet in der CLI kurz die CII to UBL-Konvertierung durch. Vielen Dank schon vorweg!

[Andreas-LBC]

Wir besprechen uns. Danke fürs Feedback.

[mfernau]

Hallo zusammen,

ich möchte mich an dieser Stelle auch kurz melden, da es durch Mustang in unserer Anwendung nun zu Mischungen der SLF4J und damit zu Fehlern kommt. Das liegt daran, weil in der Mustang-Library teile von SLF4J integriert sind und durch andere Libraries bei uns (welche ebenfalls SLF4J benötigen) verwendet werden - aber eben in der falschen Version. Das bringt uns leider vor gravierende Probleme. Wenn es also keine einfach Lib (ohne Abhängigkeiten) von Mustang gib und es uns somit nicht möglich ist die transitiven Abhängigkeiten durch unser Build-Tool auflösen zu lassen, muss ich Mustang aus unserer Anwendung ausgliedern und als externe Anwendung nur bei Bedarf starten. Das macht leider alles wesentlich komplizierter als nötig.
Gibt es hier Bestrebungen die Uber-Jar wieder in eine "einfache" lib umzuwandeln?

Schöne Grüße
Martin

[jstaerk]

Ich kann nicht genug betonen, wie sehr ich mich über einen pull request freuen würde, der das Über-JAR vermeidet und mit dem trotzdem in der CLI die CII-to-UBL-Umwandlung funktioniert.

[jstaerk]

Thanks a lot for the PR, will come in the next version

[florianklumb]

Hi Jochen,

Coming from your reply in #262 we looked into the source and JAR and it seems the PR was - at least in parts - overwritten by recent commits so shading was deactivated again. What was the reasoning behind this?

Also, is activating shading in itself enough? Don't you need to rename or relocate the dependencies in question? (https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html)

Thanks

Florian

[florianklumb]

We linked our project to a self-compiled JAR of #257 and it works. So we would really like a shaded version of Mustang!

[quadrik]

Yes my PR was partly overwritten; in library/pom.xml shadedArtifactAttached should be set to true . Only then you have the option of choosing the slim jar

<dependency>
  <groupId>org.mustangproject</groupId>
  <artifactId>library</artifactId>
</dependency>

or the uber jar:

<dependency>
  <groupId>org.mustangproject</groupId>
  <artifactId>library</artifactId>
  <classifier>shaded</classifier>
</dependency>