Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Erste SchritteWo steht eigentlich das ein jar keine andere jars enthalten darf?
ich habe schon oft gelesen, dass ein jar keine anderen jars enthalten darf. Gibt es da auch ne offizielle Festlegung? Also ich kann zwar jars in jars haben, aber das würde ja keinen Sinn machen wenn ich die in den inneren jars enthaltenen Klassen brauche.
Klar geht das! Schon mal ein Runnable Jar bei Eclipse exportiert? Entweder werden die Jars dann zu einer zusammengefügt, oder sie bleiben als Ganzes in dem entstehenden Jar enthalten.
Klar geht das! Schon mal ein Runnable Jar bei Eclipse exportiert? Entweder werden die Jars dann zu einer zusammengefügt, oder sie bleiben als Ganzes in dem entstehenden Jar enthalten.
Also alle abhängikeiten in eine Jar repacken ist s*****e, da dies Lizenzrechtliche Probleme bringt.
Und jars in jars verschachteln geht in diesem Fall auch nur, dadurch dass Eclipse einen eigenen jar-in-jar Classloader mit reinpackt. Funktioniert aber auch nicht immer zuverlässig.
Ja, das kann passieren, muss aber nicht. Du kannst ja auch eine Menge eigener Jars rekombinieren und im Detail hängt es von der jeweiligen Lizenz ab.
Ich hatte technisch bislang noch nie ein Problem damit gehabt, und darum drehte sich die Frage schließlich.
Ich hab in meinem aktuellen Projekt eine Kombination gewählt. Plugins kann man als einzelnes JAR ausliefern, wenn man nur Abhängigkeiten gegen das Framework hat oder als ZIP wenn man eigene Abhängigkeiten hat (z.B. an nen Cache System wie EHcache). Letzteres wird dann in ein temporäres Verzeichnis (work/myzip/...) entpackt und von da geladen.
1. Jar-in-Jar ist ebenso Schwachfug wie IrgendEinAndererPacker-in-IrgendEinAndererPacker, weil das zuvor komprimierte stets weiteren und damit wieder mehr Platz einnimmt, z.B. ganz allein durch die Info, dass eine Datei unkomprimiert in ein Archiv eingefügt wurde.
2. Klassen aus Jar-in-Jar klappt immer dann vorzüglich, wenn man die URL zum Bytecode kennt. Leider muss dazu das innere Archiv in ein temporäres Verzeichnis kopiert werden, damit man eine solche bekommt. Aus diesem Grund kann man sich Jar-in-Jar von vorneherein ebenfalls sparen.
1. Jar-in-Jar ist ebenso Schwachfug wie IrgendEinAndererPacker-in-IrgendEinAndererPacker, weil das zuvor komprimierte stets weiteren und damit wieder mehr Platz einnimmt, z.B. ganz allein durch die Info, dass eine Datei unkomprimiert in ein Archiv eingefügt wurde.
2. Klassen aus Jar-in-Jar klappt immer dann vorzüglich, wenn man die URL zum Bytecode kennt. Leider muss dazu das innere Archiv in ein temporäres Verzeichnis kopiert werden, damit man eine solche bekommt. Aus diesem Grund kann man sich Jar-in-Jar von vorneherein ebenfalls sparen.
Nope heisst unbedingt Nein? Ich sag' mal, eine Anwendung zwecks Verbreitung mit all seinen Archiven und Zeugs in einem Container zu halten, geht durchaus in Ordnung. Aber eine solche Anwendung bei ständiger Verwendung in diesem Zustand zu belassen, ist celebrale Diarrhoe (mein neues Lieblingswort... kann mir nicht helfen :lol. Wenn das jeder machen würde, wären wir bald bei Jar-in-Jar-in-Jar-uswmoe. Und ja, den URLClassloader kenn' ich bereits; Ist für das Nachladen von Jar-Archiven ausserhalb des eigentlich gesetzten Klassenpfades sehr hilfreich.
Kurzum: Nirgends steht, das Jar-in-Jar verboten ist, aber auf jeden Fall sollte man wissen, wann es Sinn macht und wann nicht.
Naja, RMI und JNDI-Lookups, sicher auch Reflection darunter. Kurz zum testen als jar-in-jar exportiert, und bumm, ClassNotFoundException. Mit den Jars in einen Ordner neben der hauptjar hat es tadellos funktioniert.
Tut es eh automatisch -> Eclipse JarInJarClassLoader. Wird ja beim Runnable Jar Export von Eclipse automatisch mit reingepackt. Trotzdem konnte diverse Klassen dann nicht aufgelöst werden.
Die Frage ist ja wie der arbeitet. Es reicht ja nicht, dass da nur ein Classloader ist, schließlich gibt es ja auch RMIClassLoader... ClassLoading ist halt kein einfaches Thema und doch behaupte ich, dass es in jedem Fall möglich ist diese Strategie zu fahren, eben immer mit der Einschränkung zu überlegen: Macht es überhaupt Sinn?