Hi Markus, I'll let someone official comment on the "correct" way of doing things, but here's my unofficial comments:
What you describe sounds good to me. That's what the Delta-Handlers are for. Also, I would not leave the initial install to default bootstrapping. You can override the methods getExtraInstallTasks() and/or getBasicInstallTasks() in your ModuleVersionHandler. In this method, you can specify what happens when your module is *first* installed. So you can add a bunch of BootstrapSingleResourceTasks to your getBasicInstallTasks() and control the order in which the files are bootstrapped. We work in this way in our Magnolia development. We pack all the configuration changes for our modules into ModuleVersionHandlers in this way. We also created a special module which contains all our instance- and customer-specific configuration - in this module we make configuration changes to magnolia's configuration, such as changing the commands, filter and caching configuration. In this way, by installing our "customer-module", the configuration of the magnolia instance is immediately correct for the respective customer. I found this convenient, as there are normally quite a few changes to configure to make a default magnolia ready for the customer, and packing these changes into a module means they are documented, and nothing is forgotten. We elected not to handle template, dialog and site configurations in this way. We decided that we wanted to be "fast and flexible" when working with the templates, and having to deploy them via JAR files would slow us down a lot. For this reason our templates and dialog configurations are not in any module. Instead we use the Online-Templating module, the WebDAV module, the XML-import-export as well as Magnolia's Packager module to handle development of templates, resources and dialog configurations. Regards from Vienna, Richard -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Markus Malkusch Gesendet: Dienstag, 08. Mai 2012 08:40 An: [email protected] Betreff: [magnolia-user] Bootstrapping and VersionHandler Hi can someone explain the magnolia way of injecting updates into a distributed development environment? At the moment we have no productive release. When we're deploying our first release everything should be bootstrapped to the latest version. Therefore Magnolia simply imports the XML exports in myModule.jar/mgnl- bootstrap/myModule/*. How can I preserve the order of the imports? And now the question about the VersionHandler. Our developers don't want to bootstrap every time new updates come in. Changes in the JCR are distributed as a VersionHandler delta via our version control system. Theses changes are obviously the same JCR-exports which are used for bootstrapping. At the moment we extend the DefaultModuleVersionHandler and register a task for every version. Theses tasks do nothing more than importing the correct set of these JCR export files. My question is, is this the correct Magnolia way of distributing JCR-changes? ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
