Externe Library in Jar einbinden

Miness

Mitglied
Hi Community,

ich habe eine kleine Library geschrieben und verwende darin Google Gson, um Einstellungen im JSON-Format exportieren zu können.

Um Gson einzubinden, habe ich die Lib in mein Eclipse-Projekt nach lib/gson-1.7.1.jar kopiert.

Jetzt geht es ans Packen meines Projekts in ein eigenes Jar-File.
Wie macht ihr das jeweils, liefert ihr externe Libraries immer direkt als Jar in eurem Jar mit? Oder gebt ihr an, dass euer Projekt Abhängigkeiten hat und diese vom User selber heruntergeladen und eingebunden werden müssen? Oder entpackt ihr die Library und kopiert die benötigten Klassen einfach so in euer Jar (meines Erachtens sollte auch das lizenzrechtlich kein Problem sein, Gson steht unter der Apache Lizenz)?

Wenn das direkte Mitliefern als Jar die beste Möglichkeit wäre, wie exportiert ihr das Projekt dann jeweils mit Eclipse? Als "Runnable Jar"?

Danke für euren Rat!
 
Keine der von dir genannten Methoden ist sonderlich sinnvoll.
Üblerweise liefert man die eigenen Jars und die third party Libraries gemeinsam (zB als Zip) aus.
Third Party Libraries wandern dabei oft in ein 'lib' Verzeichnis.
 
Nun ja, ich hatte gedacht, dass es in diese Richtung irgend eine sinnvolle Möglichkeit gibt (damit ich eben nur ein Jar-File veröffentlichen kann). Mit dem Entpacken der Library würde es funktionieren, finde ich aber auch nicht besonders schön.

Dann werde ich wohl deine Lösung umsetzen, danke. Auf dem obersten Verzeichnis im ZIP alle eigenen Jars, und im Unterordner "lib" des ZIPs alle Third Party Libs.
 
Ein Jar bringt viele Nachteile mit sich. Wieviele ernsthafte Programme kennst du, die aus nur einer Datei bestehen?

Natürlich gibt es wenige ausführbare Programme, die aus einer einzelnen Datei bestehen. Aber für eine Library, die ja eigentlich kein Programm an sich ist, wäre es eben schön, wenn der User nur ein Jar in sein Projekt einbinden könnte und alles funktionieren würde.

Welche Nachteile (ausser dem mit den externen Libs) sprichst du an? Ich finde Jars sonst eigentlich ziemlich praktisch.
 
Wildcard hat nichts gegen JAR (behaupte ich mal), sondern wollte damit nur ausdrücken, dass JAR in JAR suboptimal ist.

Stell dir vor, du nutzt Gson 2.x und jemand der deine Library nutzt, möchte jetzt lieber Gson 3.x nutzen (mit 2.x kompatibel). Wenn du jetzt bei dir GSON im JAR drin hast, kann er unter umständen das update auf Gson 3.x nur sehr schwer machen.

Zudem weiß ich garnicht, ob beim vielbesagtem JAR-in-JAR eine Verwendung als Bibliothek funktioniert.
 
@mvitz:

Danke, das ist natürlich ein Argument. 😉

Mittlerweile habe ich auch irgendwo gelesen, dass ein Jar in einem Jar gar nicht funktioniert. Ich werde also deshalb jetzt definitiv die Methode von Wildcard verwenden.
 
Mittlerweile habe ich auch irgendwo gelesen, dass ein Jar in einem Jar gar nicht funktioniert.
Richtig, das geht nur mit speziellen Classloader. Auch das repacking (also Bibltiotheken auspacken und in die eigene jar packen) kommt mit vielen Problemen daher. Ein paar davon:
  • kann lizenztechnisch problematisch sein
  • verkompliziert den Buildprozess
  • es besteht die Möglichkeit das sich Klassen oder Resourcen überschreiben
  • das entstandene Archiv ist ein Mix mehrere Lizenzen. Würde ich nicht mit der Kneifzange anfassen
  • Lib X lässt sich nicht mehr gegen Lib X mit wichtigem Bugfix austauschen
 
@Wildcard:

Danke für die Erläuterungen. Habe mir schon gedacht, dass es da einige Punkte gibt, die gegen ein Entpacken einer Library sprechen.
 

Neue Themen


Zurück
Oben