13 Jun
2008
13 Jun
'08
12:02 p.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs