> The good solution for this is to have an application manager component > with the following features: > > * Install/Uninstall/Upgrade applications > * Manage dependencies/prereqs between apps and with core runtime > * Download updates from a remote repo (the first implementation should > be done with a maven remote repo) (since you need some info about the > latest released version, etc and this exists in a maven repo) > * Supports installing not only pages but also jars, skin extensions/ > interface extensions. > > This app manager would replace both the packager code in core and the > current app manager plugin/application. > > What this means in practice is that your pages/extensions/plugins/etc > (in XE, XWS or others) would be split into applications managed by > this app manager. So when we update these apps we deploy them in the > remote repo and all users get notifications of new apps through the > app manager. > > Right now everyone is already busy: new rendering, new wysiwyg, new > administration. > What I'd like to do (in this order): > 1) new rendering refactoring (for Sept) > 2) new model and new related components > 3) new storage and new query components > 4) new app manager > > What this means is that I don't foresee the new app manager to be > ready before next year (and probably more likely to be middle/end of > the year). > > What it also means is that in the meantime you have 2 solutions: > 1) make upgrades manual and list in the release notes the list of > pages changed/added/removed and let admins update their installs > accordingly > 2) develop something ad hoc (something like what you propose I guess) > with the knowledge that it'll be thrown away in the future and > replaced by the app manager. > > WDYT?
Yes I cannot agree more : a proper application manager is the way to go :) As for now, I think I will first try to not have this need, and if I really have to, I'll do some ad hoc upgrading code, as solution 1) is not applicable for my use case (upgrading tenth or more of workspaces -the space abstraction, not the product itself- that is, adding new documents in N existing spaces). Jerome. > > Thanks > -Vincent > > On Jun 13, 2008, at 10:44 AM, Jerome Velociter wrote: > >> Hello devs, >> >> I'm currently trying to find the best approach to automatically >> upgrade an >> XWS instance workspaces when upgrading the XWS version. By that, I >> mean >> adding new pages to existing workspaces for example. >> I see at least two possible approaches : >> >> * On display of the workspace, we check that the considered pages are >> present, and if not either we automatically create them, either we >> offer a >> big button to "upgrade" the workspace. (the test could be done in a >> skin >> template, so that any page would trigger the upgrade) >> >> * On plugin init, we search for all workspaces and upgrade the ones in >> need. And we could have a marker once the upgrade is done, not to >> execute >> the query at each init. >> >> WDYT ? Are there other approaches I'm missing ? >> >> Regards, >> Jerome. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
