Viele JARs und deren Resourcen

[KrokoDiehl]

Hallo zusammen.
Ich habe aktuell ein Problem bzw. Klärungsbedarf, bei dem ich mal Rat und Meinungen brauche.
Folgende Situation:
Wir haben mehrere kleinere Anwendungen die als JAR vorliegen und in eine größere Anwendung integriert werden. Das läuft soweit.
Problematisch ist nun der Punkt Resourcen. Ich rede hier mal nur von Bildern, aber es bezieht sich auch auf andere. Wir haben derzeit folgende Struktur in den einzelnen JARs:

app1.jar
   -- package1
       -- package21 
       -- package22
       -- ...
   -- resources
       -- icons.properties
       -- (andere properties)
       -- icons
           -- ok.png
           -- cancel.png
           -- (usw)

Damit werden über

ResourceBundle.getBundle("resources/icons")

die Properties geladen und über die ClassLoader analog die Icons.
Das läuft bei den einzelnen Anwendungsteilen super.
Wenn nun aber das große Programm kommt und die ganzen kleineren JARs lädt, dann überschreiben/-schneiden sich offenbar (und logischerweise) die /resourcen-Verzeichnisse, da hier die Namen und die Struktur in allen JARs gleich ist.

Nun meine Frage: Gibt es einen Weg das zu umgehen oder es besser zu lösen? Ich habe mit ClassLoadern bisher nur wenig gemacht und nehme z.B. stets

this.getClass().getClassLoader()

, aber vielleicht gibt es hier schon eine andere Möglichkeit, die pro JAR unterscheidet. Dann bliebe halt noch der Aufruf zum Laden von "resources/icons", welches es im Verbund dann auch mehrmals gibt. Ganz zu schweigen davon, wenn es mehrmals die Datei ok.png gibt

Von anderen Stelle habe ich gehört, dass sie extra ein JAR mit Resourcen gemacht haben, wo eben alle drin sind. Dies wäre auch eine Option, aber dann müsste ich bei jedem kleinen Anwendungsteil (der auch separat verwendet werden kann), das dicke JAR mit allen Grafiken/Resourcen mitführen, von denen 80% niemals verwendet werden.

Weitere Alternative: Die Gleichheit der Namensgebung irgendwie auflösen... dann müssten aber ziemlich viele Projekte angepasst werden *autsch*.

Also brainstormt mal Vielleicht bin ich auch auf dem Holzweg.
Danke im Voraus.

 

[Michael...]

Zu Deinem Problem wüsste ich momentan keine Lösung...

Eventuell gibt's eine Möglichkeit mit eigenen ClassLoadern für jedes jar, aber dazu kenne ich mich zu wenig mit dem Thema aus.

... aber ich hätte einen Klugscheisserhinweis ;-)
Wehret den Anfängen --> Resourcen vernünftig in die package Struktur einbinden

 

[Empire Phoenix]

Jao das Problem wenn man sich bei Packages nicht an naming conventions hält... Eine saubere Lösung ist nur alle kleinen anwendungen in ein einzelnes package zu packen.

 

[FArt]

Du kannst zur Laufzeit für jedes Jar mit Ressourcen (das sollte vorher natürlich noch nicht im Klassenpfad sein) einen eigenen UrlClassloader definieren und über den dann die Ressourcen aus einem JAR laden. Dazu ist es u.U. nicht sehr praktisch, wenn Klassen und Ressourcen vermischt werden.

Prinzipiell ist es nicht gut, wenn verschiedene Ressourcen unter der gleichen URI über den Klassenpfad zu laden sind. In der Regel ist das ein ungünstiges (schlechtes) Assembly der Applikation.

 

[KrokoDiehl]

Gut, das Thema "Umstrukturieren der Resourcen" will ich nicht ganz abtun. Lieber einmal die Mühe noch reinstecken solange es noch geht
Um mal Größen zu nennen, so haben die bisherigen Anwendüngchen zwischen 10 und 20 Icons und 2-3 properties (pro Locale, was aktuell aber nur eine ist...).

Was wäre denn ein ordentliche Struktur? Ich würde nun sagen jene:

com/firma/app1/(sourcen)
com/firma.app1/resources/blabla.properties
com/firma.app1/resources/icons/ok.png
com/firma.app1/resources/icons/cancel.png
(...)

D.h. die bisherige /resources-Struktur soweit nach hinten schieben, bis sie im Package mit der Teilanwendung landet. Damit hätte man die Namenseindeutigkeit. Oder irre ich?

Worin ich jedenfalls keinen Sinn sehe, ist die Resourcen soweit aufzuteilen, dass sie "neben" den Klassen liegen, sprich etwas à la

com/firma/app1/gui/win/MyDialog.class
com/firma/app1/gui/win/MyDialog.properties
com/firma/app1/gui/win/ok.png
com/firma/app1/gui/win/cancel.png
com/firma/app1/gui/views/MyView.class
com/firma/app1/gui/views/MyView.properties
com/firma/app1/gui/views/ok.png
com/firma/app1/gui/views/cancel.png
(...)

Mal abgesehen davon, dass ich das meinen Chefs wirklich gut erklären müsste, hat man hier ja eine maximale Streuung... Ich bin doch dafür die Resourcen auch räumlich beisammen zu halten.

Aber sagt ruhig, was der rechte Weg laut Theorie ist, oder worin ihr Vor- und Nachteile seht. Wäre die hier genannte erste Option eine Lösung für mein Problem oder stoße ich danach auf weitere?

Und danke schonmal

 

[FArt]

Mit vermischen meinte ich: Klassen und Ressourcen in einem JAR, wie es in deinem Beispiel oben gemacht ist. Es wäre u.U. sinnvoller die Ressourcen in ein extra JAR zu packen.

Warum müssen die Ressourcen von verschiedenen Applikationen in ein JAR (oder zumindest in einen Klassenpfad)???

 

[maki]

Irgenwie klingt das als ob ein Modul- bzw. Pluginsystem fehlt

 

[KrokoDiehl]

Also es ist schonmal kein Plugin-System im eigentlichen Sinne. Die Historie ist, dass es einige kleinere Anwendungen gibt (im Hausgebrauch "Tools" genannt), die an-und-für-sich auch eigenständige Anwendungen bleiben (die meisten sind noch C/C++ basiert). Das istzB ein Tool mit dem man sich ein paar benutzerbezogene Daten aus einer DB holen kann, ein Tool mit dem man Einstellungen und Konfigurationen editieren kann... usw.
All diese kleinen Tools haben natürlich auch eigene Icons, bzw. können u.U. eigene Icons (bzw. Resourcen generell haben).

Nun gibt es u.A. das Vorhaben diese Tools auch in eine Gesamtanwendung zu integrieren ...ja, hier sieht es schon nach Plugins aus... aber dennoch die Möglichkeit zu behalten, dass sie selbstständig lauffähig und auslieferbar sind.

Von daher sage ich zu

Irgenwie klingt das als ob ein Modul- bzw. Pluginsystem fehlt

mal "ja, so kann man das nennen"
Das System bisher war, dass jedes (bisher in Java realisierte) Tool eben das /resources-Paket hat. Das wurde mal so festgelegt, weil man dann sagen kann, dass alle Tools zumindest darin ähneln. Natürlich entsteht damit das genannte Problem beim Integrieren mehrerer Tools ...das fiel mir nun dieser Tage auf.
Sprich hier muss was getan werden:

a) Das Resourcen-System überarbeiten, oder
b) das Integrieren dieser Tools anders regeln (...was bisher als der klar unsaubere Weg scheint).

Nun geht's mir eben darum, was denn eine saubere Handhabe der Resourcen wäre?
FArt's Idee mit einer extra JAR mit allen Resourcen habe ich auch schon von anderen gehört. Scheint mir auch prinzipiell sinnvoll, nur für unseren Fall hinderlich, da es bedeuten würde, dass jedes Tool, wenn es eigenständig verwendet wird, das dicke JAR mit allen Resourcen (von denen es nur einen Teil braucht) zu verwenden.
Daher tendiere ich momentan zu der Lösung, die ich in meinem zweiten Post genannt habe (die Resourcen in der Package-Struktur nach hinten schieben, dass sie hier namenseindeutig sind).
Aber ich (wir) will nicht in einem halben Jahr wieder da stehen und denken "Mist, wenn wir nun XY machen wollen, ist diese Resourcen-Struktur total Banane". Daher meine Frage in diese Profirunde

Wie es in der Realität so ist, kann ich nunmal nicht für mich entscheiden, wie's gemacht wird. Aktuell sammle ich Lösungen samt Pros und Contras. Das letzte Wort hat eh der Projektverantwortliche

 

[FArt]

Nun gibt es u.A. das Vorhaben diese Tools auch in eine Gesamtanwendung zu integrieren ...ja, hier sieht es schon nach Plugins aus... aber dennoch die Möglichkeit zu behalten, dass sie selbstständig lauffähig und auslieferbar sind.

Ich würde behaupten, das ist nicht unbedingt so einfach möglich. Die Ressourcen sind m.E. nur der Anfang. Wie sieht es mit Libraries aus (Logging API, ...)? Verwenden alle Applikationen immer die gleiche Version und bleibt das so? Eine Applikation, die nicht für so einen Einsatz konzipiert ist, verwendet gerne auch mal statische Bereiche, die sie plötzlich mit anderen Applikationen teilen muss, das ganze evtl. unsynchronisiert....

Die beste Lösung wäre, jede Applikation sorgt für eine Eindeutigkeit der Ressourcen. Wenn das wirklich das einzige Problem ist dann steht einer Integration nichts mehr im Wege, sonst kann es problematischer werden...

 

[KrokoDiehl]

Also danke euch für die Anmerkungen. Ich habe nun genug um damit intern mal ne Diskussion anzustoßen
Wenn ich's nicht vergesse, schreibe ich das Ergebnis. Ansonsten ist das Thema nun zu.
*Tür zumach*