33 lines
1.7 KiB
Markdown
33 lines
1.7 KiB
Markdown
# Synopsis
|
|
|
|
Maven Module um Magnolia Update Tasks auszuführen. Diese Update Tasks sind in ModuleUpdates gebundelt.
|
|
Magnolia Bundles welche diese Funktionalität implementieren wollen, müssen IntranetUpdateModuleVersionHandler implementieren
|
|
und als Version Handler setzten.
|
|
In den meisten Fällen reicht es hierfür IntranetUpdateModuleVersionHandler#getModuleConfig() zu implementieren und ein Object
|
|
von Typ IntranetUpdateModuleConfig zurückzugeben.
|
|
|
|
In IntranetUpdateModuleConfig können 3 Konfigurationen gesetzt werden:
|
|
|
|
* List<Task> getInitialUpdateTasks()
|
|
* Eine Liste von Tasks die bei einem ersten Startup ausgeführt werden sollen
|
|
* String getYamlUpdateDir()
|
|
* Filepath in von dem Bootstrap Yamls ausgelesen werden sollen
|
|
* String getUpdateTaskPackage()
|
|
* Java Package aus den Implementierungen von ModuleUpdate ausgelesen werden sollen
|
|
|
|
## Module Update
|
|
Module Updates funktionieren hierbei genauso wie SimpleUpdates. Es gibt 3 verschiedene Arten von Tasks.
|
|
|
|
* Generelle Tasks die ausgeführt werden sollen
|
|
* Yaml Bootstrap Files
|
|
* Tasks die nachdem Bootstrap ausgeführt werden sollen
|
|
|
|
Jedes ModuleUpdate File muss der folgenden NamingConvention entsprechen `V<yyyyMMddHHmmss>_<SomeDescription>.java`.
|
|
|
|
## Allgemeine Funktionsweise
|
|
|
|
1. Tasks aus List<Task> getInitialUpdateTasks() werden ausgeführt, falls das Module initial installiert wird
|
|
2. ModuleUpdates werden über Reflection aus dem angegebenen Path initiiert und ausgeführt
|
|
1. Sollte ein Task aus dem ModuleUpdate erfolgreich durchgeführt werden, dann wird ein Eintrag in JCR unter der Module Config in einem Version Node gespeichert
|
|
2. Falls diese Version in diesem Task schon vorhanden ist, wird dieser Task ignoriert
|