Re: update mechanism: tasks to be executed always

[Magnolia - Dev mailing list]

Hi,

Following some internal discussions, we decided to remove this for  
the 3.5 release. I was personally unconvinced by the implementation,  
given the fact that startup tasks are imho not in their place within  
a Module's version handler. They're better off in the  
ModuleLifecycle. Also, we've been thinking about introducing multiple  
"phases" in the startup process, but for lack of time and  
conclusions, we did not.
The only module that was using startup tasks was cache, and I moved  
these to CacheModule (which implements ModuleLifecycle), which I  
think is much more appropriate. One thing that might be missing is  
the global "save/rollback" that the install/update process has. We  
could think about reimplementing something similar around the  
lifecycle. We could also think about making the Task api useable in  
that context.

Please let us know if you have any custom code that suffers from  
this. I'll gladly help on this very specific subject, since this is a  
last minute and unexpected change. It would also help us understand  
better any other potential use case for this.

Cheers,

greg

ps: MAGNOLIA-1801 is where it's at.

On Oct 25, 2007, at 16:48 , Grégory Joseph wrote:

> Back on this subject - since there are similarities with blocking  
> tasks as per MAGNOLIA-1767 - I'm refactoring the processStartupTasks
> () method a little to try and remove the current code duplication.  
> Fabrizio : was the intention to save after each module's startup  
> tasks or only once after all modules? It's not clear since the  
> "success" variable is initialized outside the modules' loop and  
> there are no testcases ;)
>
> Thx
>
> g
>
> On Aug 23, 2007, at 19:50 , Philipp Bracher wrote:
>
>> Without going into details I do agree to Fabrizio:
>>
>> - a startup task is not an install and not an update task, even if  
>> you could use the same mechanism (was not obvious to me ether)
>>
>> - the lifecycle (or phases) for calling start method of the module  
>> and startup tasks are not exactly the same because the startup  
>> tasks are execute before any of the module is started.
>>
>> I'm sure that other phases will be introduced in future and I can  
>> see no harm in that.
>>
>> Philipp Bracher
>>
>>
>> On 22.08.2007, at 20:31, Fabrizio Giustina wrote:
>>
>>> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>>>>
>>>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
>>>> The getDeltas() method can be reimplemented by each and every  
>>>> module
>>>> if it needs to.
>>>> (which is where you could potentially always return certain  
>>>> deltas if
>>>> you want to systematically run certain tasks at startup - and I see
>>>> you coming with the "i don't want a gui for this" argument, but you
>>>> fixed that already ;) )
>>>
>>> the difference is that normal update task MAY have a gui, sometimes
>>> that's desired and sometimes not so I added a way to turn it off.  
>>> Task
>>> that should be executed always must not require a user confirmation.
>>> If we say that everything is controlled by the same configuration
>>> parameter this means that if we adds tasks that should always be
>>> executed we are forced to disable the gui for everything, which  
>>> is not
>>> want we want.
>>>
>>>>> and
>>>>> doesn't handle the fact that if this configuration is removed  
>>>>> from an
>>>>> existing repository, nobody will ever set it back and the  
>>>>> manager will
>>>>> keep throwing its NPE.
>>>>
>>>> This will be the case for each and every piece of configuration
>>>> that's expected to be there by any kind of "manager", right ?
>>>> I'm in favor of sanity checks, but if users mess up their
>>>> configuration, I'd just expect the Magnolia instance to die
>>>> peacefully, not try to resuscitate itself.
>>>
>>> mh... sorry, but I think that keeping magnolia alive is better: we
>>> don't touch anything existing, but if a standard configuration has
>>> been deleted readding it back would not hurt. The only way for
>>> recovering from a similar situation at this moment is re-
>>> bootstrapping
>>> the whole config repository (if you are unable to load  
>>> admininterface)
>>> and that's absolutely worst
>>>
>>>> Well, given my comments above. I don't really see the point, since
>>>> this seems to duplicate what is/can be done in  
>>>> ModuleLifecycle.start() ?
>>>
>>> a couple of valid reason:
>>> - modulemanager already handles "transactional" update, loading all
>>> the tasks and applying changes only if everything went ok. There  
>>> is a
>>> lot of boilerplate code for doing this, what's the point of
>>> replicating this bunch of code in every single module?
>>> - doing that in module manager means also that startup tasks are
>>> executed for all the modules and only after that each module is
>>> started. Doing that in ModuleLifecycle.start() means that you  
>>> will run
>>> task/start for each single module: if you have to check a
>>> configuration that is used by another module too (i.e. filters)  
>>> that's
>>> not optimal at all.
>>>
>>> please have a look at the current implementation in svn, IMHO it  
>>> looks
>>> easy and clean. It's easy for user to add tasks if they want and
>>> nothing changes if you don't need them. The code in module  
>>> manager is
>>> clean and there is no added complexity.
>>>
>>> fabrizio
>>>
>>> ----------------------------------------------------------------
>>> 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
> ----------------------------------------------------------------

----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

On Nov 15, 2007 9:05 PM, Grégory Joseph <dev-list@...> wrote:
> Following some internal discussions, we decided to remove this for
> the 3.5 release. I was personally unconvinced by the implementation,
> given the fact that startup tasks are imho not in their place within
> a Module's version handler. They're better off in the
> ModuleLifecycle. Also, we've been thinking about introducing multiple
> "phases" in the startup process, but for lack of time and
> conclusions, we did not.

should this have been discussed before removing them????
sorry, but I implemented them for a reason and this was already
discussed, for me that feature is really needed and I can't understand
why I should remove it without warning just because you are not
convinced and without giving an alternative.

For me this means that I will not be able to upgrade to magnolia 3.5
and that I will need to keep using 3.1 M builds (and to be clear, this
means that the customer will not buy Magnolia licenses!).
I have been asked to discuss important changes in the dev list before
doing anything, I'd like to see  this from your side too, Greg...
apart from the fact that you didn't need them and you was not
personally convinced by the implementation was there any problem in
leaving everything as it was??

fabrizio

> The only module that was using startup tasks was cache, and I moved
> these to CacheModule (which implements ModuleLifecycle), which I
> think is much more appropriate. One thing that might be missing is
> the global "save/rollback" that the install/update process has. We
> could think about reimplementing something similar around the
> lifecycle. We could also think about making the Task api useable in
> that context.
>
> Please let us know if you have any custom code that suffers from
> this. I'll gladly help on this very specific subject, since this is a
> last minute and unexpected change. It would also help us understand
> better any other potential use case for this.
>
> Cheers,
>
> greg
>
> ps: MAGNOLIA-1801 is where it's at.
>
> On Oct 25, 2007, at 16:48 , Grégory Joseph wrote:
>
> > Back on this subject - since there are similarities with blocking
> > tasks as per MAGNOLIA-1767 - I'm refactoring the processStartupTasks
> > () method a little to try and remove the current code duplication.
> > Fabrizio : was the intention to save after each module's startup
> > tasks or only once after all modules? It's not clear since the
> > "success" variable is initialized outside the modules' loop and
> > there are no testcases ;)
> >
> > Thx
> >
> > g
> >
> > On Aug 23, 2007, at 19:50 , Philipp Bracher wrote:
> >
> >> Without going into details I do agree to Fabrizio:
> >>
> >> - a startup task is not an install and not an update task, even if
> >> you could use the same mechanism (was not obvious to me ether)
> >>
> >> - the lifecycle (or phases) for calling start method of the module
> >> and startup tasks are not exactly the same because the startup
> >> tasks are execute before any of the module is started.
> >>
> >> I'm sure that other phases will be introduced in future and I can
> >> see no harm in that.
> >>
> >> Philipp Bracher
> >>
> >>
> >> On 22.08.2007, at 20:31, Fabrizio Giustina wrote:
> >>
> >>> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
> >>>>
> >>>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
> >>>> The getDeltas() method can be reimplemented by each and every
> >>>> module
> >>>> if it needs to.
> >>>> (which is where you could potentially always return certain
> >>>> deltas if
> >>>> you want to systematically run certain tasks at startup - and I see
> >>>> you coming with the "i don't want a gui for this" argument, but you
> >>>> fixed that already ;) )
> >>>
> >>> the difference is that normal update task MAY have a gui, sometimes
> >>> that's desired and sometimes not so I added a way to turn it off.
> >>> Task
> >>> that should be executed always must not require a user confirmation.
> >>> If we say that everything is controlled by the same configuration
> >>> parameter this means that if we adds tasks that should always be
> >>> executed we are forced to disable the gui for everything, which
> >>> is not
> >>> want we want.
> >>>
> >>>>> and
> >>>>> doesn't handle the fact that if this configuration is removed
> >>>>> from an
> >>>>> existing repository, nobody will ever set it back and the
> >>>>> manager will
> >>>>> keep throwing its NPE.
> >>>>
> >>>> This will be the case for each and every piece of configuration
> >>>> that's expected to be there by any kind of "manager", right ?
> >>>> I'm in favor of sanity checks, but if users mess up their
> >>>> configuration, I'd just expect the Magnolia instance to die
> >>>> peacefully, not try to resuscitate itself.
> >>>
> >>> mh... sorry, but I think that keeping magnolia alive is better: we
> >>> don't touch anything existing, but if a standard configuration has
> >>> been deleted readding it back would not hurt. The only way for
> >>> recovering from a similar situation at this moment is re-
> >>> bootstrapping
> >>> the whole config repository (if you are unable to load
> >>> admininterface)
> >>> and that's absolutely worst
> >>>
> >>>> Well, given my comments above. I don't really see the point, since
> >>>> this seems to duplicate what is/can be done in
> >>>> ModuleLifecycle.start() ?
> >>>
> >>> a couple of valid reason:
> >>> - modulemanager already handles "transactional" update, loading all
> >>> the tasks and applying changes only if everything went ok. There
> >>> is a
> >>> lot of boilerplate code for doing this, what's the point of
> >>> replicating this bunch of code in every single module?
> >>> - doing that in module manager means also that startup tasks are
> >>> executed for all the modules and only after that each module is
> >>> started. Doing that in ModuleLifecycle.start() means that you
> >>> will run
> >>> task/start for each single module: if you have to check a
> >>> configuration that is used by another module too (i.e. filters)
> >>> that's
> >>> not optimal at all.
> >>>
> >>> please have a look at the current implementation in svn, IMHO it
> >>> looks
> >>> easy and clean. It's easy for user to add tasks if they want and
> >>> nothing changes if you don't need them. The code in module
> >>> manager is
> >>> clean and there is no added complexity.
> >>>
> >>> fabrizio
> >>>
> >>> ----------------------------------------------------------------
> >>> 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
> > ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> 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
----------------------------------------------------------------

[Magnolia - Dev mailing list]

On Nov 15, 2007, at 21:39 , Fabrizio Giustina wrote:

> On Nov 15, 2007 9:05 PM, Grégory Joseph <dev-list@...>  
> wrote:
>> Following some internal discussions, we decided to remove this for
>> the 3.5 release. I was personally unconvinced by the implementation,
>> given the fact that startup tasks are imho not in their place within
>> a Module's version handler. They're better off in the
>> ModuleLifecycle. Also, we've been thinking about introducing multiple
>> "phases" in the startup process, but for lack of time and
>> conclusions, we did not.
>
> should this have been discussed before removing them????
> sorry, but I implemented them for a reason and this was already
> discussed, for me that feature is really needed and I can't understand
> why I should remove it without warning just because you are not
> convinced and without giving an alternative.

I thought I did, and moved the implementation accordingly: the  
alternative is ModuleLifecycle.start(). See the CacheModule class,  
for instance. [1]

If that doesn't fulfill your needs, as I've said, I'd be happy to  
help and try to understand and find a good solution with you.

> For me this means that I will not be able to upgrade to magnolia 3.5
> and that I will need to keep using 3.1 M builds (and to be clear, this
> means that the customer will not buy Magnolia licenses!).
> I have been asked to discuss important changes in the dev list before
> doing anything, I'd like to see  this from your side too, Greg...
> apart from the fact that you didn't need them and you was not
> personally convinced by the implementation was there any problem in
> leaving everything as it was??

Yes, the fact that we're thinking about introducing multiple "phases"  
in the startup process, which is likely to mean this would have moved  
anyway. We didn't want to introduce a feature, knowing we'd move/
remove/change it in the next version, as we'd rather avoid the hassle  
of deprecating/maintaining deprecated code.

The ModuleVersionHandler interface is intended to help handling the  
different versions of a module, which means installing/updating its  
configuration between updates of a Magnolia-based system. The  
ModuleLifecycle is intended to handle the lifecycle of a module  
during the lifetime of a Magnolia instance (i.e server restart), and  
with its start() method, I believe one can implement the same that  
was possible with the startup tasks. I had plans on extending the  
ModuleLifecycleContext so that it would have the same handy methods  
as the InstallContext (getCurrentModuleNode etc). Would that help ?

Regarding not discussing the issue before: we have commitments for  
pushing this release out today. I know this is definitely not a nice  
thing to do. Convince us that it needs to be there, and it might make  
its way back (one svn commit is easy to revert); rest assured,  
though, that it's nothing personal (I didn't just go and remove it  
because I didn't like it;))

Cheers

greg

[1] http://svn.magnolia.info/view/magnolia/trunk/magnolia-module- 
cache/src/main/java/info/magnolia/cms/cache/CacheModule.java?
rev=12605&view=diff&r1=12605&r2=12604&p1=magnolia/trunk/magnolia-
module-cache/src/main/java/info/magnolia/cms/cache/
CacheModule.java&p2=/magnolia/trunk/magnolia-module-cache/src/main/
java/info/magnolia/cms/cache/CacheModule.java

>> The only module that was using startup tasks was cache, and I moved
>> these to CacheModule (which implements ModuleLifecycle), which I
>> think is much more appropriate. One thing that might be missing is
>> the global "save/rollback" that the install/update process has. We
>> could think about reimplementing something similar around the
>> lifecycle. We could also think about making the Task api useable in
>> that context.
>>
>> Please let us know if you have any custom code that suffers from
>> this. I'll gladly help on this very specific subject, since this is a
>> last minute and unexpected change. It would also help us understand
>> better any other potential use case for this.
>>
>> Cheers,
>>
>> greg
>>
>> ps: MAGNOLIA-1801 is where it's at.
>>
>> On Oct 25, 2007, at 16:48 , Grégory Joseph wrote:
>>
>>> Back on this subject - since there are similarities with blocking
>>> tasks as per MAGNOLIA-1767 - I'm refactoring the processStartupTasks
>>> () method a little to try and remove the current code duplication.
>>> Fabrizio : was the intention to save after each module's startup
>>> tasks or only once after all modules? It's not clear since the
>>> "success" variable is initialized outside the modules' loop and
>>> there are no testcases ;)
>>>
>>> Thx
>>>
>>> g
>>>
>>> On Aug 23, 2007, at 19:50 , Philipp Bracher wrote:
>>>
>>>> Without going into details I do agree to Fabrizio:
>>>>
>>>> - a startup task is not an install and not an update task, even if
>>>> you could use the same mechanism (was not obvious to me ether)
>>>>
>>>> - the lifecycle (or phases) for calling start method of the module
>>>> and startup tasks are not exactly the same because the startup
>>>> tasks are execute before any of the module is started.
>>>>
>>>> I'm sure that other phases will be introduced in future and I can
>>>> see no harm in that.
>>>>
>>>> Philipp Bracher
>>>>
>>>>
>>>> On 22.08.2007, at 20:31, Fabrizio Giustina wrote:
>>>>
>>>>> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>>>>>>
>>>>>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
>>>>>> The getDeltas() method can be reimplemented by each and every
>>>>>> module
>>>>>> if it needs to.
>>>>>> (which is where you could potentially always return certain
>>>>>> deltas if
>>>>>> you want to systematically run certain tasks at startup - and  
>>>>>> I see
>>>>>> you coming with the "i don't want a gui for this" argument,  
>>>>>> but you
>>>>>> fixed that already ;) )
>>>>>
>>>>> the difference is that normal update task MAY have a gui,  
>>>>> sometimes
>>>>> that's desired and sometimes not so I added a way to turn it off.
>>>>> Task
>>>>> that should be executed always must not require a user  
>>>>> confirmation.
>>>>> If we say that everything is controlled by the same configuration
>>>>> parameter this means that if we adds tasks that should always be
>>>>> executed we are forced to disable the gui for everything, which
>>>>> is not
>>>>> want we want.
>>>>>
>>>>>>> and
>>>>>>> doesn't handle the fact that if this configuration is removed
>>>>>>> from an
>>>>>>> existing repository, nobody will ever set it back and the
>>>>>>> manager will
>>>>>>> keep throwing its NPE.
>>>>>>
>>>>>> This will be the case for each and every piece of configuration
>>>>>> that's expected to be there by any kind of "manager", right ?
>>>>>> I'm in favor of sanity checks, but if users mess up their
>>>>>> configuration, I'd just expect the Magnolia instance to die
>>>>>> peacefully, not try to resuscitate itself.
>>>>>
>>>>> mh... sorry, but I think that keeping magnolia alive is better: we
>>>>> don't touch anything existing, but if a standard configuration has
>>>>> been deleted readding it back would not hurt. The only way for
>>>>> recovering from a similar situation at this moment is re-
>>>>> bootstrapping
>>>>> the whole config repository (if you are unable to load
>>>>> admininterface)
>>>>> and that's absolutely worst
>>>>>
>>>>>> Well, given my comments above. I don't really see the point,  
>>>>>> since
>>>>>> this seems to duplicate what is/can be done in
>>>>>> ModuleLifecycle.start() ?
>>>>>
>>>>> a couple of valid reason:
>>>>> - modulemanager already handles "transactional" update, loading  
>>>>> all
>>>>> the tasks and applying changes only if everything went ok. There
>>>>> is a
>>>>> lot of boilerplate code for doing this, what's the point of
>>>>> replicating this bunch of code in every single module?
>>>>> - doing that in module manager means also that startup tasks are
>>>>> executed for all the modules and only after that each module is
>>>>> started. Doing that in ModuleLifecycle.start() means that you
>>>>> will run
>>>>> task/start for each single module: if you have to check a
>>>>> configuration that is used by another module too (i.e. filters)
>>>>> that's
>>>>> not optimal at all.
>>>>>
>>>>> please have a look at the current implementation in svn, IMHO it
>>>>> looks
>>>>> easy and clean. It's easy for user to add tasks if they want and
>>>>> nothing changes if you don't need them. The code in module
>>>>> manager is
>>>>> clean and there is no added complexity.
>>>>>
>>>>> fabrizio

----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

On Nov 15, 2007 10:18 PM, Grégory Joseph <dev-list@...> wrote:

> On Nov 15, 2007, at 21:39 , Fabrizio Giustina wrote:
> I thought I did, and moved the implementation accordingly: the
> alternative is ModuleLifecycle.start(). See the CacheModule class,
> for instance. [1]

there are two important thinks missing:
- the automatic handling of a global save/rollback
- the ability to use "normal" update tasks that you can also use in a
module upgrade. If the sample you were referring at is the static
AddCacheVoterTask.addVoter() that is definitively only an hack, not
anything really usable.

So, I would be glad to agree that this kind of tasks could fit well in
a ModuleLifecycle implementation, but please rollback that change
until there is a real alternative that fulfill those needs please.
Mark the method with a clear "this will be moved somewhere else soon",
but put it back...


fabrizio
         
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

Ok..  so the 18 million euro question -- will there be a built-in
upgrade path for current users of 3.0 -> 3.5?  Will exporting the
production website and dropping those files into mangolia 3.5 work?  
This sounds like it's going to start being a deal breaker if Magnolia
becomes know as a product with no migration/upgrade path.

--David

Grégory Joseph wrote:

> Hi,
>
> Following some internal discussions, we decided to remove this for the
> 3.5 release. I was personally unconvinced by the implementation, given
> the fact that startup tasks are imho not in their place within a
> Module's version handler. They're better off in the ModuleLifecycle.
> Also, we've been thinking about introducing multiple "phases" in the
> startup process, but for lack of time and conclusions, we did not.
> The only module that was using startup tasks was cache, and I moved
> these to CacheModule (which implements ModuleLifecycle), which I think
> is much more appropriate. One thing that might be missing is the
> global "save/rollback" that the install/update process has. We could
> think about reimplementing something similar around the lifecycle. We
> could also think about making the Task api useable in that context.
>
> Please let us know if you have any custom code that suffers from this.
> I'll gladly help on this very specific subject, since this is a last
> minute and unexpected change. It would also help us understand better
> any other potential use case for this.
>
> Cheers,
>
> greg
>
> ps: MAGNOLIA-1801 is where it's at.
>
> On Oct 25, 2007, at 16:48 , Grégory Joseph wrote:
>
>> Back on this subject - since there are similarities with blocking
>> tasks as per MAGNOLIA-1767 - I'm refactoring the
>> processStartupTasks() method a little to try and remove the current
>> code duplication. Fabrizio : was the intention to save after each
>> module's startup tasks or only once after all modules? It's not clear
>> since the "success" variable is initialized outside the modules' loop
>> and there are no testcases ;)
>>
>> Thx
>>
>> g
>>
>> On Aug 23, 2007, at 19:50 , Philipp Bracher wrote:
>>
>>> Without going into details I do agree to Fabrizio:
>>>
>>> - a startup task is not an install and not an update task, even if
>>> you could use the same mechanism (was not obvious to me ether)
>>>
>>> - the lifecycle (or phases) for calling start method of the module
>>> and startup tasks are not exactly the same because the startup tasks
>>> are execute before any of the module is started.
>>>
>>> I'm sure that other phases will be introduced in future and I can
>>> see no harm in that.
>>>
>>> Philipp Bracher
>>>
>>>
>>> On 22.08.2007, at 20:31, Fabrizio Giustina wrote:
>>>
>>>> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>>>>>
>>>>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
>>>>> The getDeltas() method can be reimplemented by each and every module
>>>>> if it needs to.
>>>>> (which is where you could potentially always return certain deltas if
>>>>> you want to systematically run certain tasks at startup - and I see
>>>>> you coming with the "i don't want a gui for this" argument, but you
>>>>> fixed that already ;) )
>>>>
>>>> the difference is that normal update task MAY have a gui, sometimes
>>>> that's desired and sometimes not so I added a way to turn it off. Task
>>>> that should be executed always must not require a user confirmation.
>>>> If we say that everything is controlled by the same configuration
>>>> parameter this means that if we adds tasks that should always be
>>>> executed we are forced to disable the gui for everything, which is not
>>>> want we want.
>>>>
>>>>>> and
>>>>>> doesn't handle the fact that if this configuration is removed
>>>>>> from an
>>>>>> existing repository, nobody will ever set it back and the manager
>>>>>> will
>>>>>> keep throwing its NPE.
>>>>>
>>>>> This will be the case for each and every piece of configuration
>>>>> that's expected to be there by any kind of "manager", right ?
>>>>> I'm in favor of sanity checks, but if users mess up their
>>>>> configuration, I'd just expect the Magnolia instance to die
>>>>> peacefully, not try to resuscitate itself.
>>>>
>>>> mh... sorry, but I think that keeping magnolia alive is better: we
>>>> don't touch anything existing, but if a standard configuration has
>>>> been deleted readding it back would not hurt. The only way for
>>>> recovering from a similar situation at this moment is re-bootstrapping
>>>> the whole config repository (if you are unable to load admininterface)
>>>> and that's absolutely worst
>>>>
>>>>> Well, given my comments above. I don't really see the point, since
>>>>> this seems to duplicate what is/can be done in
>>>>> ModuleLifecycle.start() ?
>>>>
>>>> a couple of valid reason:
>>>> - modulemanager already handles "transactional" update, loading all
>>>> the tasks and applying changes only if everything went ok. There is a
>>>> lot of boilerplate code for doing this, what's the point of
>>>> replicating this bunch of code in every single module?
>>>> - doing that in module manager means also that startup tasks are
>>>> executed for all the modules and only after that each module is
>>>> started. Doing that in ModuleLifecycle.start() means that you will run
>>>> task/start for each single module: if you have to check a
>>>> configuration that is used by another module too (i.e. filters) that's
>>>> not optimal at all.
>>>>
>>>> please have a look at the current implementation in svn, IMHO it looks
>>>> easy and clean. It's easy for user to add tasks if they want and
>>>> nothing changes if you don't need them. The code in module manager is
>>>> clean and there is no added complexity.
>>>>
>>>> fabrizio
>>>>    
>>>> ----------------------------------------------------------------
>>>> 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
>> ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> for list details see
> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
> ----------------------------------------------------------------

--
David Smith
Network Operations Supervisor
Department of Entomology
Cornell University
2132 Comstock Hall
Ithaca, NY 14853
Phone: [phone]
Fax: [phone]


----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

On Nov 15, 2007, at 22:53 , David Smith wrote:

> Ok..  so the 18 million euro question -- will there be a built-in  
> upgrade path for current users of 3.0 -> 3.5?  Will exporting the  
> production website and dropping those files into mangolia 3.5  
> work?  This sounds like it's going to start being a deal breaker if  
> Magnolia becomes know as a product with no migration/upgrade path.

Err, the only thing that was removed here is a feature that never  
made it in any release, not even a milestone.
I'm not sure I followed you, here.

g

> --David
>
> Grégory Joseph wrote:
>> Hi,
>>
>> Following some internal discussions, we decided to remove this for  
>> the 3.5 release. I was personally unconvinced by the  
>> implementation, given the fact that startup tasks are imho not in  
>> their place within a Module's version handler. They're better off  
>> in the ModuleLifecycle. Also, we've been thinking about  
>> introducing multiple "phases" in the startup process, but for lack  
>> of time and conclusions, we did not.
>> The only module that was using startup tasks was cache, and I  
>> moved these to CacheModule (which implements ModuleLifecycle),  
>> which I think is much more appropriate. One thing that might be  
>> missing is the global "save/rollback" that the install/update  
>> process has. We could think about reimplementing something similar  
>> around the lifecycle. We could also think about making the Task  
>> api useable in that context.
>>
>> Please let us know if you have any custom code that suffers from  
>> this. I'll gladly help on this very specific subject, since this  
>> is a last minute and unexpected change. It would also help us  
>> understand better any other potential use case for this.
>>
>> Cheers,
>>
>> greg
>>
>> ps: MAGNOLIA-1801 is where it's at.
>>
>> On Oct 25, 2007, at 16:48 , Grégory Joseph wrote:
>>
>>> Back on this subject - since there are similarities with blocking  
>>> tasks as per MAGNOLIA-1767 - I'm refactoring the  
>>> processStartupTasks() method a little to try and remove the  
>>> current code duplication. Fabrizio : was the intention to save  
>>> after each module's startup tasks or only once after all modules?  
>>> It's not clear since the "success" variable is initialized  
>>> outside the modules' loop and there are no testcases ;)
>>>
>>> Thx
>>>
>>> g
>>>
>>> On Aug 23, 2007, at 19:50 , Philipp Bracher wrote:
>>>
>>>> Without going into details I do agree to Fabrizio:
>>>>
>>>> - a startup task is not an install and not an update task, even  
>>>> if you could use the same mechanism (was not obvious to me ether)
>>>>
>>>> - the lifecycle (or phases) for calling start method of the  
>>>> module and startup tasks are not exactly the same because the  
>>>> startup tasks are execute before any of the module is started.
>>>>
>>>> I'm sure that other phases will be introduced in future and I  
>>>> can see no harm in that.
>>>>
>>>> Philipp Bracher
>>>>
>>>>
>>>> On 22.08.2007, at 20:31, Fabrizio Giustina wrote:
>>>>
>>>>> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>>>>>>
>>>>>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
>>>>>> The getDeltas() method can be reimplemented by each and every  
>>>>>> module
>>>>>> if it needs to.
>>>>>> (which is where you could potentially always return certain  
>>>>>> deltas if
>>>>>> you want to systematically run certain tasks at startup - and  
>>>>>> I see
>>>>>> you coming with the "i don't want a gui for this" argument,  
>>>>>> but you
>>>>>> fixed that already ;) )
>>>>>
>>>>> the difference is that normal update task MAY have a gui,  
>>>>> sometimes
>>>>> that's desired and sometimes not so I added a way to turn it  
>>>>> off. Task
>>>>> that should be executed always must not require a user  
>>>>> confirmation.
>>>>> If we say that everything is controlled by the same configuration
>>>>> parameter this means that if we adds tasks that should always be
>>>>> executed we are forced to disable the gui for everything, which  
>>>>> is not
>>>>> want we want.
>>>>>
>>>>>>> and
>>>>>>> doesn't handle the fact that if this configuration is removed  
>>>>>>> from an
>>>>>>> existing repository, nobody will ever set it back and the  
>>>>>>> manager will
>>>>>>> keep throwing its NPE.
>>>>>>
>>>>>> This will be the case for each and every piece of configuration
>>>>>> that's expected to be there by any kind of "manager", right ?
>>>>>> I'm in favor of sanity checks, but if users mess up their
>>>>>> configuration, I'd just expect the Magnolia instance to die
>>>>>> peacefully, not try to resuscitate itself.
>>>>>
>>>>> mh... sorry, but I think that keeping magnolia alive is better: we
>>>>> don't touch anything existing, but if a standard configuration has
>>>>> been deleted readding it back would not hurt. The only way for
>>>>> recovering from a similar situation at this moment is re-
>>>>> bootstrapping
>>>>> the whole config repository (if you are unable to load  
>>>>> admininterface)
>>>>> and that's absolutely worst
>>>>>
>>>>>> Well, given my comments above. I don't really see the point,  
>>>>>> since
>>>>>> this seems to duplicate what is/can be done in  
>>>>>> ModuleLifecycle.start() ?
>>>>>
>>>>> a couple of valid reason:
>>>>> - modulemanager already handles "transactional" update, loading  
>>>>> all
>>>>> the tasks and applying changes only if everything went ok.  
>>>>> There is a
>>>>> lot of boilerplate code for doing this, what's the point of
>>>>> replicating this bunch of code in every single module?
>>>>> - doing that in module manager means also that startup tasks are
>>>>> executed for all the modules and only after that each module is
>>>>> started. Doing that in ModuleLifecycle.start() means that you  
>>>>> will run
>>>>> task/start for each single module: if you have to check a
>>>>> configuration that is used by another module too (i.e. filters)  
>>>>> that's
>>>>> not optimal at all.
>>>>>
>>>>> please have a look at the current implementation in svn, IMHO  
>>>>> it looks
>>>>> easy and clean. It's easy for user to add tasks if they want and
>>>>> nothing changes if you don't need them. The code in module  
>>>>> manager is
>>>>> clean and there is no added complexity.
>>>>>
>>>>> fabrizio
>>>>>      
>>>>> ----------------------------------------------------------------
>>>>> 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
>>> ----------------------------------------------------------------
>>
>>
>> ----------------------------------------------------------------
>> for list details see
>> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
>> ----------------------------------------------------------------
>
>
> --
> David Smith
> Network Operations Supervisor
> Department of Entomology
> Cornell University
> 2132 Comstock Hall
> Ithaca, NY 14853
> Phone: [phone]
> Fax: [phone]
>
>
> ----------------------------------------------------------------
> 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
----------------------------------------------------------------

[Magnolia - Dev mailing list]

> Ok..  so the 18 million euro question -- will there be a built-in  
> upgrade path for current users of 3.0 -> 3.5?

Yes ;-)

> Will exporting the production website and dropping those files into  
> mangolia 3.5 work?

You take your 3.0 application and stop it, drop the new jars,  
startup. The update UI tells you what to do and will update the  
system accordingly by changing the configuration as smart as  
possible. So not even an export import needed.

>   This sounds like it's going to start being a deal breaker if  
> Magnolia becomes know as a product with no migration/upgrade path.

The issue we discuss here is a feature added in 3.5 and then removed  
in the last second.

The rc1 will be ready for download in some hours! Please test the  
update mechanism so that we can ensure the upgrade path for your  
system ;-)

Philipp Bracher

>
> --David
>
> Grégory Joseph wrote:
>> Hi,
>>
>> Following some internal discussions, we decided to remove this for  
>> the 3.5 release. I was personally unconvinced by the  
>> implementation, given the fact that startup tasks are imho not in  
>> their place within a Module's version handler. They're better off  
>> in the ModuleLifecycle. Also, we've been thinking about  
>> introducing multiple "phases" in the startup process, but for lack  
>> of time and conclusions, we did not.
>> The only module that was using startup tasks was cache, and I  
>> moved these to CacheModule (which implements ModuleLifecycle),  
>> which I think is much more appropriate. One thing that might be  
>> missing is the global "save/rollback" that the install/update  
>> process has. We could think about reimplementing something similar  
>> around the lifecycle. We could also think about making the Task  
>> api useable in that context.
>>
>> Please let us know if you have any custom code that suffers from  
>> this. I'll gladly help on this very specific subject, since this  
>> is a last minute and unexpected change. It would also help us  
>> understand better any other potential use case for this.
>>
>> Cheers,
>>
>> greg
>>
>> ps: MAGNOLIA-1801 is where it's at.
>>
>> On Oct 25, 2007, at 16:48 , Grégory Joseph wrote:
>>
>>> Back on this subject - since there are similarities with blocking  
>>> tasks as per MAGNOLIA-1767 - I'm refactoring the  
>>> processStartupTasks() method a little to try and remove the  
>>> current code duplication. Fabrizio : was the intention to save  
>>> after each module's startup tasks or only once after all modules?  
>>> It's not clear since the "success" variable is initialized  
>>> outside the modules' loop and there are no testcases ;)
>>>
>>> Thx
>>>
>>> g
>>>
>>> On Aug 23, 2007, at 19:50 , Philipp Bracher wrote:
>>>
>>>> Without going into details I do agree to Fabrizio:
>>>>
>>>> - a startup task is not an install and not an update task, even  
>>>> if you could use the same mechanism (was not obvious to me ether)
>>>>
>>>> - the lifecycle (or phases) for calling start method of the  
>>>> module and startup tasks are not exactly the same because the  
>>>> startup tasks are execute before any of the module is started.
>>>>
>>>> I'm sure that other phases will be introduced in future and I  
>>>> can see no harm in that.
>>>>
>>>> Philipp Bracher
>>>>
>>>>
>>>> On 22.08.2007, at 20:31, Fabrizio Giustina wrote:
>>>>
>>>>> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>>>>>>
>>>>>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
>>>>>> The getDeltas() method can be reimplemented by each and every  
>>>>>> module
>>>>>> if it needs to.
>>>>>> (which is where you could potentially always return certain  
>>>>>> deltas if
>>>>>> you want to systematically run certain tasks at startup - and  
>>>>>> I see
>>>>>> you coming with the "i don't want a gui for this" argument,  
>>>>>> but you
>>>>>> fixed that already ;) )
>>>>>
>>>>> the difference is that normal update task MAY have a gui,  
>>>>> sometimes
>>>>> that's desired and sometimes not so I added a way to turn it  
>>>>> off. Task
>>>>> that should be executed always must not require a user  
>>>>> confirmation.
>>>>> If we say that everything is controlled by the same configuration
>>>>> parameter this means that if we adds tasks that should always be
>>>>> executed we are forced to disable the gui for everything, which  
>>>>> is not
>>>>> want we want.
>>>>>
>>>>>>> and
>>>>>>> doesn't handle the fact that if this configuration is removed  
>>>>>>> from an
>>>>>>> existing repository, nobody will ever set it back and the  
>>>>>>> manager will
>>>>>>> keep throwing its NPE.
>>>>>>
>>>>>> This will be the case for each and every piece of configuration
>>>>>> that's expected to be there by any kind of "manager", right ?
>>>>>> I'm in favor of sanity checks, but if users mess up their
>>>>>> configuration, I'd just expect the Magnolia instance to die
>>>>>> peacefully, not try to resuscitate itself.
>>>>>
>>>>> mh... sorry, but I think that keeping magnolia alive is better: we
>>>>> don't touch anything existing, but if a standard configuration has
>>>>> been deleted readding it back would not hurt. The only way for
>>>>> recovering from a similar situation at this moment is re-
>>>>> bootstrapping
>>>>> the whole config repository (if you are unable to load  
>>>>> admininterface)
>>>>> and that's absolutely worst
>>>>>
>>>>>> Well, given my comments above. I don't really see the point,  
>>>>>> since
>>>>>> this seems to duplicate what is/can be done in  
>>>>>> ModuleLifecycle.start() ?
>>>>>
>>>>> a couple of valid reason:
>>>>> - modulemanager already handles "transactional" update, loading  
>>>>> all
>>>>> the tasks and applying changes only if everything went ok.  
>>>>> There is a
>>>>> lot of boilerplate code for doing this, what's the point of
>>>>> replicating this bunch of code in every single module?
>>>>> - doing that in module manager means also that startup tasks are
>>>>> executed for all the modules and only after that each module is
>>>>> started. Doing that in ModuleLifecycle.start() means that you  
>>>>> will run
>>>>> task/start for each single module: if you have to check a
>>>>> configuration that is used by another module too (i.e. filters)  
>>>>> that's
>>>>> not optimal at all.
>>>>>
>>>>> please have a look at the current implementation in svn, IMHO  
>>>>> it looks
>>>>> easy and clean. It's easy for user to add tasks if they want and
>>>>> nothing changes if you don't need them. The code in module  
>>>>> manager is
>>>>> clean and there is no added complexity.
>>>>>
>>>>> fabrizio
>>>>>      
>>>>> ----------------------------------------------------------------
>>>>> 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
>>> ----------------------------------------------------------------
>>
>>
>> ----------------------------------------------------------------
>> for list details see
>> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
>> ----------------------------------------------------------------
>
>
> --
> David Smith
> Network Operations Supervisor
> Department of Entomology
> Cornell University
> 2132 Comstock Hall
> Ithaca, NY 14853
> Phone: [phone]
> Fax: [phone]
>
>
> ----------------------------------------------------------------
> 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
----------------------------------------------------------------

[Magnolia - Dev mailing list]

> - the automatic handling of a global save/rollback
???

> - the ability to use "normal" update tasks that you can also use in a
> module upgrade. If the sample you were referring at is the static
> AddCacheVoterTask.addVoter() that is definitively only an hack, not
> anything really usable.
Understood.

OK, we will revert the commit but marking the method immediately as  
deprecated.

Philipp Bracher

----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

Cool and thanks... I will definitely be testing that.  My confusion
stems from the subject and I suspect most of the dev conversations never
make it onto the dev list.  It's become pretty much just the JIRA
announce list.

--David

Philipp Bracher wrote:

>> Ok..  so the 18 million euro question -- will there be a built-in
>> upgrade path for current users of 3.0 -> 3.5?
>
> Yes ;-)
>
>> Will exporting the production website and dropping those files into
>> mangolia 3.5 work?
>
> You take your 3.0 application and stop it, drop the new jars, startup.
> The update UI tells you what to do and will update the system
> accordingly by changing the configuration as smart as possible. So not
> even an export import needed.
>
>>   This sounds like it's going to start being a deal breaker if
>> Magnolia becomes know as a product with no migration/upgrade path.
>
> The issue we discuss here is a feature added in 3.5 and then removed
> in the last second.
>
> The rc1 will be ready for download in some hours! Please test the
> update mechanism so that we can ensure the upgrade path for your
> system ;-)
>
> Philipp Bracher
>
>>
>> --David
>>
>> Grégory Joseph wrote:
>>> Hi,
>>>
>>> Following some internal discussions, we decided to remove this for
>>> the 3.5 release. I was personally unconvinced by the implementation,
>>> given the fact that startup tasks are imho not in their place within
>>> a Module's version handler. They're better off in the
>>> ModuleLifecycle. Also, we've been thinking about introducing
>>> multiple "phases" in the startup process, but for lack of time and
>>> conclusions, we did not.
>>> The only module that was using startup tasks was cache, and I moved
>>> these to CacheModule (which implements ModuleLifecycle), which I
>>> think is much more appropriate. One thing that might be missing is
>>> the global "save/rollback" that the install/update process has. We
>>> could think about reimplementing something similar around the
>>> lifecycle. We could also think about making the Task api useable in
>>> that context.
>>>
>>> Please let us know if you have any custom code that suffers from
>>> this. I'll gladly help on this very specific subject, since this is
>>> a last minute and unexpected change. It would also help us
>>> understand better any other potential use case for this.
>>>
>>> Cheers,
>>>
>>> greg
>>>
>>> ps: MAGNOLIA-1801 is where it's at.
>>>
>>> On Oct 25, 2007, at 16:48 , Grégory Joseph wrote:
>>>
>>>> Back on this subject - since there are similarities with blocking
>>>> tasks as per MAGNOLIA-1767 - I'm refactoring the
>>>> processStartupTasks() method a little to try and remove the current
>>>> code duplication. Fabrizio : was the intention to save after each
>>>> module's startup tasks or only once after all modules? It's not
>>>> clear since the "success" variable is initialized outside the
>>>> modules' loop and there are no testcases ;)
>>>>
>>>> Thx
>>>>
>>>> g
>>>>
>>>> On Aug 23, 2007, at 19:50 , Philipp Bracher wrote:
>>>>
>>>>> Without going into details I do agree to Fabrizio:
>>>>>
>>>>> - a startup task is not an install and not an update task, even if
>>>>> you could use the same mechanism (was not obvious to me ether)
>>>>>
>>>>> - the lifecycle (or phases) for calling start method of the module
>>>>> and startup tasks are not exactly the same because the startup
>>>>> tasks are execute before any of the module is started.
>>>>>
>>>>> I'm sure that other phases will be introduced in future and I can
>>>>> see no harm in that.
>>>>>
>>>>> Philipp Bracher
>>>>>
>>>>>
>>>>> On 22.08.2007, at 20:31, Fabrizio Giustina wrote:
>>>>>
>>>>>> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>>>>>>>
>>>>>>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
>>>>>>> The getDeltas() method can be reimplemented by each and every
>>>>>>> module
>>>>>>> if it needs to.
>>>>>>> (which is where you could potentially always return certain
>>>>>>> deltas if
>>>>>>> you want to systematically run certain tasks at startup - and I see
>>>>>>> you coming with the "i don't want a gui for this" argument, but you
>>>>>>> fixed that already ;) )
>>>>>>
>>>>>> the difference is that normal update task MAY have a gui, sometimes
>>>>>> that's desired and sometimes not so I added a way to turn it off.
>>>>>> Task
>>>>>> that should be executed always must not require a user confirmation.
>>>>>> If we say that everything is controlled by the same configuration
>>>>>> parameter this means that if we adds tasks that should always be
>>>>>> executed we are forced to disable the gui for everything, which
>>>>>> is not
>>>>>> want we want.
>>>>>>
>>>>>>>> and
>>>>>>>> doesn't handle the fact that if this configuration is removed
>>>>>>>> from an
>>>>>>>> existing repository, nobody will ever set it back and the
>>>>>>>> manager will
>>>>>>>> keep throwing its NPE.
>>>>>>>
>>>>>>> This will be the case for each and every piece of configuration
>>>>>>> that's expected to be there by any kind of "manager", right ?
>>>>>>> I'm in favor of sanity checks, but if users mess up their
>>>>>>> configuration, I'd just expect the Magnolia instance to die
>>>>>>> peacefully, not try to resuscitate itself.
>>>>>>
>>>>>> mh... sorry, but I think that keeping magnolia alive is better: we
>>>>>> don't touch anything existing, but if a standard configuration has
>>>>>> been deleted readding it back would not hurt. The only way for
>>>>>> recovering from a similar situation at this moment is
>>>>>> re-bootstrapping
>>>>>> the whole config repository (if you are unable to load
>>>>>> admininterface)
>>>>>> and that's absolutely worst
>>>>>>
>>>>>>> Well, given my comments above. I don't really see the point, since
>>>>>>> this seems to duplicate what is/can be done in
>>>>>>> ModuleLifecycle.start() ?
>>>>>>
>>>>>> a couple of valid reason:
>>>>>> - modulemanager already handles "transactional" update, loading all
>>>>>> the tasks and applying changes only if everything went ok. There
>>>>>> is a
>>>>>> lot of boilerplate code for doing this, what's the point of
>>>>>> replicating this bunch of code in every single module?
>>>>>> - doing that in module manager means also that startup tasks are
>>>>>> executed for all the modules and only after that each module is
>>>>>> started. Doing that in ModuleLifecycle.start() means that you
>>>>>> will run
>>>>>> task/start for each single module: if you have to check a
>>>>>> configuration that is used by another module too (i.e. filters)
>>>>>> that's
>>>>>> not optimal at all.
>>>>>>
>>>>>> please have a look at the current implementation in svn, IMHO it
>>>>>> looks
>>>>>> easy and clean. It's easy for user to add tasks if they want and
>>>>>> nothing changes if you don't need them. The code in module
>>>>>> manager is
>>>>>> clean and there is no added complexity.
>>>>>>
>>>>>> fabrizio
>>>>>>     ----------------------------------------------------------------
>>>>>> 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
>>>> ----------------------------------------------------------------
>>>
>>>
>>> ----------------------------------------------------------------
>>> for list details see
>>> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
>>> ----------------------------------------------------------------
>>
>>
>> --
>> David Smith
>> Network Operations Supervisor
>> Department of Entomology
>> Cornell University
>> 2132 Comstock Hall
>> Ithaca, NY 14853
>> Phone: [phone]
>> Fax: [phone]
>>
>>
>> ----------------------------------------------------------------
>> 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
> ----------------------------------------------------------------

--
David Smith
Network Operations Supervisor
Department of Entomology
Cornell University
2132 Comstock Hall
Ithaca, NY 14853
Phone: [phone]
Fax: [phone]


----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

> OK, we will revert the commit but marking the method immediately as  
> deprecated.

done ;-)

>
> Philipp Bracher
>
> ----------------------------------------------------------------
> 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
----------------------------------------------------------------

[Magnolia - Dev mailing list]

Hi Fabrizio,

http://jira.magnolia.info/browse/MAGNOLIA-1853

Feel free to comment ;)

g

On Nov 15, 2007, at 22:32 , Fabrizio Giustina wrote:

> On Nov 15, 2007 10:18 PM, Grégory Joseph <dev-list@...>  
> wrote:
>
>> On Nov 15, 2007, at 21:39 , Fabrizio Giustina wrote:
>> I thought I did, and moved the implementation accordingly: the
>> alternative is ModuleLifecycle.start(). See the CacheModule class,
>> for instance. [1]
>
> there are two important thinks missing:
> - the automatic handling of a global save/rollback
> - the ability to use "normal" update tasks that you can also use in a
> module upgrade. If the sample you were referring at is the static
> AddCacheVoterTask.addVoter() that is definitively only an hack, not
> anything really usable.
>
> So, I would be glad to agree that this kind of tasks could fit well in
> a ModuleLifecycle implementation, but please rollback that change
> until there is a real alternative that fulfill those needs please.
> Mark the method with a clear "this will be moved somewhere else soon",
> but put it back...
>
>
> fabrizio
>
> ----------------------------------------------------------------
> 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
----------------------------------------------------------------

[Magnolia - Dev mailing list]

thanks

I'll do my best to find out a solution that works for everybody, thanks for rolling back the change for now... I would have been happy to work and refactor it for rc1, but I needed more than 10 minutes missing for the release ;)
I'll put my comments in jira MAGNOLIA-1853 , I still have some doubt that what we have now can be exactly done outsite the ModuleVersionHandler but I am happy to discuss it. Please let's try to come up with a common design decision and I'll work to implement it.

And...
congrats to everyone for the release! 3.5 is great ;)

fabrizio

On Nov 15, 2007 11:26 PM, Philipp Bracher <dev-list@...> wrote:

> OK, we will revert the commit but marking the method immediately as
> deprecated.

done ;-)

>
> Philipp Bracher

>
> ----------------------------------------------------------------
> 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
----------------------------------------------------------------