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