Hallo Patrik,
die Empfehlung von Sandro kann ich uneingeschrรคnkt unterstรผzten. Bei einem FSM sollte man รคhnlich wie bei anderen Java-Projekten vorgehen. Wenn sich eine Aufteilung bzw. Wiederverwendung ergibt dann kann man den Java-Code auf mehrere Jars aufteilen.
Abhรคngigkeiten zwischen FSMs kann man auch definieren, jedoch gibt es hier einen Punkt, der problematisch ist: Da bei der Abhรคngigkeit von FSMs deren Version nicht mit einschlieรt, kann man theoretisch inkompatible Siuationen schaffen, die erst zur Lauftzeit auffallen (z.B. durch ClassNotFoundError wenn eine รคltere Version eines Moduls A mit einer neueren Version B ersetzt wurde un dabei die Abhรคngigkeit von Modul C nicht aktualisiert wurde). Aus diesem Grund sind Abhรคngigkeiten zwischen FSMs nur etwas fรผr Spezialfรคlle und man sollte dann genau wissen was man tut.
Es gibt jedoch auch echte Szenarien, bei denen man wegen der Sichtbarkeit auf dem ClassPath innerhalb eines FSMs zwei Jars haben mรถchte. Angenommen, ich mรถchte aus einer Executable eine REST-API benutzen und setzte dafรผr eine Fremdbibliothek ein. In diesem Fall sollte die Fremdbibliothek im FSM nur mit Scope Module eingebunden werden (module.xml). Das klappt aber nicht, weil eine Executable immer public sein muss, damit sie z.B. als Executable in einem Script oder Auftrag benutzt werden kann.
Hier muss man den Aufruf der REST-API hinter einem ServerService verbergen (Fascade-Pattern). Dabei wird der ServerService mittels eines Java-Interfaces definiert. Dieses Interface kommt in ein seperates Jar welches auf Scope Server eingebunden wird (module.xml). Die Implementierung des Interfaces, also die Service-Java-Klasse kommt in zweites Jar, welches nur mit Scope Module eingebunden wird. So kรถnnen dann auch Fremdbibliotheken, welche ich im Service nutze, mit Scope Module eingebunden werden, ohne dass es zu ClassPath-Problemen kommt.
Leider wird viel zu hรคufig das eigene Modul auf einem FirstSpirit-Server mit nur einem Projekt getestet. In diesem Fall treten Probleme, die man mit Jars welche mit Scope Server eingebunden hat nie auf. Das ist aber nicht Realitรคt. Unsere Kunden benutzen ja hรคufig ein paar Module zusammen und haben wegen Internationalisierung auch viele Projekte. Wenn ich im Produkt-Management eine Zertifizierung eines Moduls mache, ist das Prรผfen der module.xml meine Lieblingsaufgabe. Oft reicht das schon, um eine Nachbesserung einzufordern, da dort typische Fehler bei der Architektur gemacht wurden. Im Grunde verhรคlt sich bei FirstSpirit Modulen nicht viel รคnders als bei OSGi-Bundles, da man hier auch sehr genau auf die Sichtbarkeit der verwendeten Fremdbibliotheken achten muss.
Grรผรe
Marian
MichaelaReydt
marza