> I'd like to open a discussion on how to implement a module installer for > magnolia. I currently see two solutions and was wondering if there are other > solutions around people are thinking about. Thanks. For those who have not followed the discussions so far, we plan to make a very first and basic step for Magnolia 4.3. See the concept page [1]
> > solution a: installer/module manager is outside of magnolia > - we add an additional war file on to the server - that additional war is > responsible to manage the modules in the magnolia instances of the server and > can also redeploy the magnolia war files in order to apply the changes I don't have that much against having an independent installer. But this being a webapp doesn't sound that right to me. I can't see the advantage over b as this webapp will be very dependent on the container and a restart after an installation/update can be omitted. > solution b: magnolia gets an internal module page where one can download a > module and run it. I'm wondering however in that scenario if magnolia can be > shut down enough and started again without having to restart the app server. Hot-deployment and so on can be added later and needs some essential architectural changes. For now we can just add some convenience: - list available modules (also third party modules which might have different licenses) - list available/recommended updates - dependency check (get the appropriate list of modules for the current version) - download link - installation instructions (some of the modules just need additional step beside just dropping the jar) > Sidenote: it might be a good idea to move the module jar files into the > magnolia jcr repository instead of just dropping them into the WEB-INF/lib > path. Loading of a jar file can be achieved over a dircontext extension the > same way it was done for the better templating module - however, this is app > server dependent and different app servers handle the dircontext differently. > A guide on how to do this can be taken from the spring framework runtime AOP > weaving (they had to tackle the same problem). Thanks for the hint. > Would be great to hear other ideas/approaches and what your fav approach > would be. There is something which I consider as important as the download / installation part. I am talking about giving the user the option to hand some information to the installation process. Following some concrete examples: - install samples (yes/no) - mail server - public/author instance It would probably be not to complicated to add that to the installation/update mechanism. [1] http://wiki.magnolia-cms.com/display/DEV/Module+store ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
