Verbessertes Module Version Handling

Einführung

Der Magnolia Module-Mechanismus erlaubt es Entwicklern, den Lebenszyklus von Magnolia Modulen zu verwalten. Jedes Magnolia Module definiert in seinem Module-Deskriptor XML File verschiedene Module-Klassen, wovon eine der sogenannte VersionHandler ist. (Siehe Module descriptor elements). Im Module-Descriptor registriere ich also eine Klasse, welche das ModuleVersionHandler Interface implementiert. Magnolia stellt hier bereits Basisklassen zur Verfügung, welche sich z.B. um die Unterscheidung von zwischen Install- oder Update-Modus kümmern.

In diesem kurzen Post möchte ich zeigen, wie man die Magnolia Klassen erweitern kann, um möglichst effizient verschiedene Use Cases der Module-Entwicklung abzudecken.

(mehr …)

Umgebungsspezifische Konfigurationen in Magnolia CMS

Einführung

Wenn ich ein grösseres Magnolia Projekt mit verschiedensten Instanzen aufsetze (local development, development, staging, integration, production), stellt sich früher oder später die Frage,  wie ich verschiedene Konfigurationen kontrolliert auf die verschiedenen Instanzen installieren kann.

In diesem Blog Post zeige ich einen einfachen Lösungsansatz auf, der sich beliebig erweitern und auf projektspezifische Bedürfnisse abstimmen lässt.

Problemstellung

Magnolia bringt out-of-the-box bereits einen Mechanismus mit, der umgebungsspezifisches Einspielen von XML Bootstrap Files erlaubt. Dieser Mechanismus ist aber beschränkt auf die Initialisierung des JCR Repositories und erlaubt deshalb weder das Einspielen von Updates via XML Files, noch eine Interaktion mit Java Code.

Im Laufe eines Projektes kommt oft der Punkt, an dem ich ein Update / Delta Task nur auf einem oder mehreren bestimmten Systemen ausführen möchte. Dazu zählen zum Beispiel das Ändern des SMTP Server im Mail Modul, oder das Aktualisieren eines Subscribers. Zudem kann es auf der lokalen Entwicklungsumgebung sinnvoll sein, bei jedem Neustart des Systems einen Teil der Konfigurationen neu zu schreiben, um die Entwicklung auf einem sauberen Stand zu starten oder Änderungen von anderen Entwicklern im eigenen Repository zu sehen.

Lösungsansatz

Im magnolia.properties File wird ein neues Property magnolia.environment definiert, welches den Namen der Umgebung beinhalten wird.

magnolia.properties

...
magnolia.environment = <env_name>
...

Dieser Lösungsansatz erfordert lediglich, dass für jede zu unterscheidende Umgebung ein eigenes magnolia.properties File existiert, was aber in grösseren Projekten weitgehend der Fall sein sollte.

Das neue Property wird durch eine simple Java Hilfsklasse ausgelesen, und erlaubt auf einfache Weise das Unterscheiden der verschiedenen Umgebungen, insbesondere der lokalen Entwicklungsumgebung. 

(mehr …)