Richard Unger wrote: > As Jan describes, the module mechanism in Magnolia is excellent! Modules can > be used to easily "move" functionality between instances. The > install-procedure for the modules is very "intelligent" - you can code > ModuleVersionHandlers and DeltaVersionHandlers which will intelligently > install your module, and can check the state of the repository to perform > different install-tasks depending on this state (for example, the module can > install differently depending on whether it is already installed before, or > depending on whether it is an author or public instance that is being > installed). > I find the modules very useful to move functionality (Java-Code like Template > and Paragraph Model-Classes) and configuration (your module's config, or > changes to the magnolia config) around between instances. > > However, I do not find that the modules are a good way to move content > around. Content is usually created by someone else, while the modules are > created by a Java-Programmer. To incorporate content into the modules > requires a lot of communication between these people. Also, there is no > "easy" way to move content from the repository into your Java Project - each > time the content changes you would have to do something like a new > XML-Export, update your module version number, change your > DeltaVersionHandler, etc... That's really a lot of work, esp. when moving > from development to test and back. > > For moving the content around, we are currently using magnolia's "packager" > module. The packager is a nice tool that allows you to define a "bundle" of > content (also from multiple workspaces), and export it in a ZIP file. That > ZIP file can be uploaded and installed in another magnolia instance. > This method works ok, but once you have several sites, and especially if the > content is changing a lot (as is normal during development), this method also > becomes quite a lot of work.
This is also something we are struggling with, especially module configuration (which is handled the same as 'content', it's just JCR data in another workspace). Our current development team setup uses a clustered development database, so any content or configuration changes are immediately available to all developers. This way developers working with module configuration don't need to export XML for every change they make and they don't need to write version handler code (our frontenders usually don't do Java). We do need to make sure to export and commit all relevant data before we do a build for our test server. We have created our own version handler which just re-bootstraps all module configuration data on every update, so we currently don't use version handlers. This strategy solves some problems (not having to export to XML very often and not having to write version handler code), but it also introduces some new ones. For instance since changes in JCR are committed asynchronously (only when test builds are created), we can't connect a JCR fix to a commit in Subversion in our bug tracker. And modules that bootstrap or modify the JCR outside of their own module configuration node are tricky as well. Long story short: we haven't settled on an ideal solution for our team yet. Nils. ------------------------------------------------------------------------ VPRO www.vpro.nl ------------------------------------------------------------------------ ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
