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
