Hi Is there a simple example on how to create a module using "new way"? Maven archeotype? Also, an example that shows simple delta tasks in action (like what would code look like to upgrade between 2 versions)?
Thanks Amir > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] > Sent: Friday, August 03, 2007 1:40 PM > To: [email protected] > Subject: Re: [magnolia-dev] Update mechanism > > Hi, > > Soooo... we finally merged the branch back to the trunk. > > A quick bullet list of things to know or note: > > * Modules should (but are not forced to) provide an > implementation of ModuleVersionHandler. This in turn provides > Magnolia with the appropriate Delta's and Task's which allow > updating a module's files or configuration from one version > to the other. See code, examples and javadoc for more details. > > * The Module class now represents the configuration of the > module, i.e it is built using content2bean, and it is not > mandatory anymore. > One of the ideas is that we wanted to separate the whole > installation/ update/registration process (which is now > handled through the > ModuleVersionHandler) from the module's business or configuration. > Old-style modules are still supported (in fact we haven't > updated all the Magnolia modules yet). The module beans can > optionally implement the ModuleLifecycle interface, which > still gives them a chance to "do stuff" on startup/shutdown. > (see below) > > * ObservedManager components are now registered by the module > that provides them. This means that magnolia-core (which is > now a module > btw) registers a few of these, magnolia-module-admininterface too. > The ModuleLifecycleContext provides a method for this. What > this also means, is that ANY module can now say "hey, I want > FooBarManager to know about all foobar nodes of all modules". > This will help separating core/admininterface/gui much > better, and will allow external modules to work with modules > like scheduler (i.e your mymodule could have a node "jobs" > which the scheduler will pick up. > This is not limited to core/admininterface components anymore) > > * We tried to make the whole thing as self-contained as > possible, which is why the javascript and css is inlined in > the pages. (though included using freemarker) - but we might > want some more eye-candy (logo, icons), so maybe we'll have > to do something about it anyway. > > There are still a lot of things to be done, but here's a > quick list of what we want to highlight, as a "yes, we know, > we're working on it" kind of list: > > * Registering servlets don't really work anymore, because the > container might try to restart the webapp after we modify the > web.xml. We're suspecting it was working before only because > this was happening in a ServletContextListener and the > container wasnt' > watching the files yet. Now it's happening during an http request. > > * Security: yes, the update pages will be protected. We'll > try to use the existing login configurable if available, or > we can also generate and log a random ID, which the > administrator can copy paste in the "login" screen of the > update pages. > > * Threading: the whole process should happen in a separate > thread rather than during the request. This would help > avoiding time outs and conflicts. (any access to the page, > once the process is started, would just display the current > state, i.e the list of tasks which have been executed, for instance) > > * Observation: some components are still started "the old > way". As a consequence, you can sometimes get stacktraces > about nodes which can't be found. No worries, once the > install or update is finished, the observers are still there > and everything just works. Our plan there is to differ the > startup of observation. (ie ObservationUtil will "buffer" all > the registerChangeListener() calls until its start > () method is called) > > Well, I think that's about it. Should you have any problem, > question, remark or suggestion, just shoot! > > Cheers > > g > > > On Jun 14, 2007, at 17:39 , Grégory Joseph wrote: > > > Hi guys, > > > > We had some brainstorming sessions today about the update > mechanism > > that will be part of Magnolia 3.1. > > > > We put our ideas down in mindmaps. While that format might not be > > ideal to read for someone who did not participate in the > meetings, we > > also see it as a good compromise between ease of creation, > maintenance > > and usefulness, as opposed to long-ish spec-ish text > documents. We'll > > be happy to provide info or clarify points that are not clear by > > themselves, and/or discuss any of them. > > > > The first one is an attempt to list all the problems to solve and > > features we'd like to see in there: > > http://www.mind42.com/pub/mindmap?mid=fd256f03-1679-4b9a-a788- > > b768bb2b2a04 > > > > The seconds focuses more on technical or practical aspects, > with some > > decisions being taken or viewpoints being adopted: > > http://www.mind42.com/pub/mindmap?mid=8f526afb-f339-4884-9a47- > > f9207e80704b > > > > Let us know what you think ! > > > > Cheers > > > > greg > > > > ---------------------------------------------------------------- > > for list details see > > http://documentation.magnolia.info/docs/en/editor/stayupdated.html > > ---------------------------------------------------------------- > > > ---------------------------------------------------------------- > for list details see > http://documentation.magnolia.info/docs/en/editor/stayupdated.html > ---------------------------------------------------------------- > ---------------------------------------------------------------- for list details see http://documentation.magnolia.info/docs/en/editor/stayupdated.html ----------------------------------------------------------------
