Thank you for these apps!
Ludovic Dubost
>
http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/Since the apps now appear to all be serialized wiki-documents saved with
extension ".xml" in subversion, what about having a simple app-installer
which avoids the entire XAR process and allows more fine-grained subversion
updating of apps. In other words, as both the application "code" and
"document" reside in subversion, installing a new Xwiki app would be as
simple as loading a single-document containing "meta" information about the
app like it's subversion repo URL, app name&description, and a manifest
listing any files that need saving with special permissions. The app would
then consult the subversion URL and reconstruct documents in the appropriate
space(s) and permissions (per manifest). E.g. documents for the
"recruitment" app would be build directly from these:
- Loading.xml<
http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/Recruitment/Loading.xml>
- Settings.xml<
http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/Recruitment/Settings.xml>
- WebHome.xml<
http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/Recruitment/WebHome.xml>
- CandidateClass.xml<
http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/RecruitmentCode/CandidateClass.xml>
- CandidateClassSheet.xml<
http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/RecruitmentCode/CandidateClassSheet.xml>
- CandidateClassTemplate.xml<
http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-recruitmentmanager/src/main/resources/RecruitmentCode/CandidateClassTemplate.xml>
- ...
Eventually,such a mechanism could entail some form of dependency-control on
updating apps, e.g. app-branches for different underlying xwiki versions;
when you upgrade to a new version of xwiki, any apps installed this way
would automatically update changed documents to their new version. Of
course, application authors would want to be able to "go the other way",
saving out whole spaces/collections of documents into an external subversion
repository...
The app would, in groovy, via HTTP, read each subversion document into a
"pipe", capturing a single document as XML "in memory" (groovy->java) and
write it to the database with set-content and save/save-with-prog-rights
Xwiki API's. As this would be done one XML file at a time, the maximum
"memory explosion" would be the size of the largest XML document (e.g.
translations doc) in the app, as opposed to the current situation. (Seems
like it would be easier to sidestep large xar export/import issues this way,
rather than trying to make XAR import export work via streaming). And of
course, if you ended up customizing an application-document on your server,
subversion would be used to merge any non-conflicting upgrades to the
document that might occur as the application is improved....
Niels
http://nielsmayer.com_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
