On 5/2/07, Grégory Joseph <[email protected]> wrote:
Actually, we also have this jira task: http://jira.magnolia.info/
browse/MAGNOLIA-1448
... where we're logging these kind of things - which we hope to
automate with an update mechanism.
yes, upgrading everything automatically is nice, but I think that the
for some cases (like the renaming of classes) the good old
@deprecation is enough and also helps in not breaking any custom
extension without explanation...
I also think that we should add the "upgrade module" asap, it could be
useful to encorage testing of the 3.1 milestones... do you have
anything ready for that or we could start sketching up something?
I *guess* removing a servlet from web.xml would be feasible too,
since we already have a mechanism to add them :)
Well, I actually never liked the fact that we are modifying *files* in
the user webapp like web.xml and repository.xml...
I would not spend a minute in adding a "remove servlet" feature,
leaving the old class as deprecated is enough for me. I would invest
that time in replacing the old servlet that require registration in
web.xml to something nicer (pages? filters? config in jcr?)... I
started this in magnolia 3.0 and we are pretty near to make the single
filter in web.xml the only requirement for magnolia, this would really
simplify upgrading (and integrating magnolia with other
webapps/frameworks)...
fabrizio
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
