We were looking at the same sort of thing, and came to the conclusion that an XSL transform on the exported content might be the way forward. This would allow you to export the content, transform it using XSL to match the new schema and then import into a fresh repo with the new schema.
Miro -----Original Message----- From: Stefan Guggisberg [mailto:[EMAIL PROTECTED] Sent: 10 April 2006 16:03 To: dev@jackrabbit.apache.org Subject: Re: Importing workspaces, content handler. hi martin On 4/9/06, Martin Perez <[EMAIL PROTECTED]> wrote: > Hi. > > The biggest issued that I'm currently facing with Jackrabbit is being able > to migrate workspaces from one version to another. For example, I have on > the recent version of my nodetypes hierarchy I have removed two properties. > This removal forces me to be able to migrate workspaces from previous > versions using some SAX parsing algorithm. > > So my approach is: > - read the exported workspace file > - Filter the content through SAX handlers > - Import the content on the new workspace. > > So my first question is do you know about better alternatives than this > approach? > > And then I would also want to raise discussion about having the possibility > of setting the import content handler on Jackrabbit. If I could extend the > current import content handler and set that customized import content > handler on the repository then it would be easier for me to perform the > migration. I think that this is also something very reasonable, to be able > to customize the import algorithm on your repositories. > > What do you think? Can I open a JIRA improvement? the current 'import' implementation is quite complex as it has to deal with a lot of 'under-the-hood' details. for that reason i would rather not make it pluggable. you could e.g. write your own sax event handler that does some custom filtering before delegating to the handler returned by Workspace#getImportContentHandler. cheers stefan > > Martin > >
