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?
Nothing ready. This is the main feature to develop for m2.
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 agree in the sense that we should keep the original files as backups
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 agree.
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)...
Saw that, but did not check it till now.
Perhaps we should not change these files (during update) but write a
warning into a special update log. Which is then showed in the admin
interface.
Philipp Bracher
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
