Questions & Answers

SOLVED
mstaender
I'm new here

Aktuelle Methode um Resourcen zu verwalten

Jump to solution

Hi,

ich habe nach einem knappen Jahr FirstSpirit-Pause mein Projekt wieder aufgenommen und muss jetzt viele Funktionen aus Executables in Server-Dienste auslagern.

Beispiel: ich wollte Benutzer aus einem externen System mit Benutzern aus FirstSpirit verknรผpfen und muss dazu die Liste der Benutzer aus unserem System in eine Datenquelle Synchronisieren.

Nachdem ich angefangen habe meine module.xml zu bearbeiten habe ich mich gefragt, ob sich irgend etwas getan hat um diese manuellen Eintrรคge in den Griff zu bekommen. Ich nutze Maven um meine Projekte zu realisieren und definiere dort z.B. Dependencies. Wenn ich nun eine Abhรคngigkeit hinzufรผge muss ich manuell in der module.xml die notwendigen Bibliotheken an den korrekten Stellen einfรผgen. Da das Projekt derzeit alles andere als stabil ist und ร„nderungen noch recht hรคufig sind frage ich mich, ob es hier Erleichterungen gibt.

Beispiel: als ich die Dienste implementiert habe war mir nicht gleich klar welcher der Dienste welche Bibliothek genau benรถtigt, da die Dienste selbst keine einzelnen Projekte sind und ich nicht einfach "alle" mรถglichen Dependencies hinzufรผgen wollte. Also fing ich mit dem an was ich wusste und fรผhrte folgenden ziemlich blรถden und zeitaufwรคndigen Prozess durch:

- baue das Projekt

- deploye es

- teste en Dienst

- wenn CNF Exception, fรผge jar hinzu, fange von vorn an

Wie regelt Ihr solche Aufgaben?

MfG Marcus

0 Kudos
1 Solution

Accepted Solutions
tenter
I'm new here

Hallo Marcus,

wir haben intern verschiedene Arten von Tooling im Einsatz, um dem genannten Problem zu begegnen.

Du kannst zum Beispiel deine Projektstrukturen etwas feiner aufteilen und nicht nur eins, sondern eine Reihe von FirstSpirit-Modulen bauen - also ein Maven-Projekt/Submodul pro Service. Das macht aber nur Sinn, wenn die Komponenten auch irgendeiner fachlichen Trennung unterliegen - wenn das thematisch alles zusammen hรคngt, dann sollte es natรผrlich ein einzelnes Modul bleiben. Je kleiner das Modul, desto einfacher wird es die Abhรคngigkeiten von Hand in der module.xml zu pflegen.

Andernfalls kรถnnen wir dir ein recht neues Tool von uns empfehlen, allerdings mรผsstest du dein Projekt dafรผr auf Gradle umstellen: [NEW] Gradle Plugins for FirstSpirit development

Fรผr dich interessant ist das FSMGradlePlugin. Hier kannst du deine Komponenten mit Java-Annotationen konfigurieren und die module.xml wird basierend auf den Abhรคngigkeiten deines Projektes generiert. Komplexere Projekte kรถnnen รผber Subprojekte strukturiert werden, die jeweils auch wieder mit eigenen Abhรคngigkeiten daherkommen kรถnnen, die automatisch funktionieren.

Schau dir mal die Dokumentation an, die du um ZIP-File findest und gib uns Bescheid, ob du damit was anfangen kannst. Klingt fรผr mich, als wรคre das genau das, was du brauchst.

GrรผรŸe,

Hannes

View solution in original post

0 Kudos
3 Replies
tenter
I'm new here

Hallo Marcus,

wir haben intern verschiedene Arten von Tooling im Einsatz, um dem genannten Problem zu begegnen.

Du kannst zum Beispiel deine Projektstrukturen etwas feiner aufteilen und nicht nur eins, sondern eine Reihe von FirstSpirit-Modulen bauen - also ein Maven-Projekt/Submodul pro Service. Das macht aber nur Sinn, wenn die Komponenten auch irgendeiner fachlichen Trennung unterliegen - wenn das thematisch alles zusammen hรคngt, dann sollte es natรผrlich ein einzelnes Modul bleiben. Je kleiner das Modul, desto einfacher wird es die Abhรคngigkeiten von Hand in der module.xml zu pflegen.

Andernfalls kรถnnen wir dir ein recht neues Tool von uns empfehlen, allerdings mรผsstest du dein Projekt dafรผr auf Gradle umstellen: [NEW] Gradle Plugins for FirstSpirit development

Fรผr dich interessant ist das FSMGradlePlugin. Hier kannst du deine Komponenten mit Java-Annotationen konfigurieren und die module.xml wird basierend auf den Abhรคngigkeiten deines Projektes generiert. Komplexere Projekte kรถnnen รผber Subprojekte strukturiert werden, die jeweils auch wieder mit eigenen Abhรคngigkeiten daherkommen kรถnnen, die automatisch funktionieren.

Schau dir mal die Dokumentation an, die du um ZIP-File findest und gib uns Bescheid, ob du damit was anfangen kannst. Klingt fรผr mich, als wรคre das genau das, was du brauchst.

GrรผรŸe,

Hannes

0 Kudos
NMc
Crownpeak employee
Crownpeak employee

Hallo Marcus,

Ich habe dich in die Gruppe fรผr das Tooling hinzugefรผgt. Was Hannes schreibt wรคre auch meine Empfehlung.

Das Erstellen eines Moduls mit dem FSM Gradle Plugin vereinfacht die ganze Angelegenheit spรผrbar.

Zusรคtzlich mรถchte ich auf das FS Gradle Plugin verweisen, mit dem das Hochfahren eines FS-Servers, Projektimport

und Modulinstallation aus dem Buildscript mรถglich werden. Unter Umstรคnden klรคrt das deine Frage bezรผglich

Testing und Deployment.

Uns ist bewusst, dass ein Umstieg auf Gradle nicht von selbst geschieht, dennoch kรถnnten die Tools

den Umstieg wert sein. Zudem ist es auch mรถglich einige Teile des Builds mit Gradle zu bauen und aus

Gradle heraus Maven aufzurufen. Damit ist auch ein sequenzieller Umstieg mรถglich.

freundliche GrรผรŸe

Nico

0 Kudos

Hi Hannes und Nico,

das klingt zunรคchst sehr interessant. Aus Zeitgrรผnden schiebe ich den Umstieg noch vor mit her aber prinzipiell scheint mir das eine sinnvolle Lรถsung. Ich muss dann noch prรผfen wie die Zusammenarbeit meiner IDE mit Gradle funktioniert, da ich mit Gradle bisher noch nichts gemacht habe.


Danke fรผr die Infos,

Marcus

0 Kudos

Type a product name