Hi Marco, Maybe I don’t understand correctly your use case, but would it be easier to simply write a script using the JCR API to do the changes in the repo?
Michael On 16/05/17 18:33, "Marco Piovesana" <[email protected]> wrote: >Hi Tomek, >yes I'm trying to upgrade within the same repository type but I can decide >weather to migrate the repository or not based on what makes the upgrade >easier. >The CommitHooks can only be used inside an upgrade to a new repository? >What is the suggested way to apply backward-incompatible changes if i don't >want to migrate the data from one repository to another but I want to apply >the modifications to the original one? > >Marco. > >On Tue, May 16, 2017 at 4:04 PM, Tomek Rekawek <[email protected]> >wrote: > >> Hi Marco, >> >> the main purpose of the oak-upgrade is to migrate a Jackrabbit 2 / CRX2 >> repository into Oak or to migrate one Oak node store (eg. segment) to >> another (like Mongo). On the other hand, it’s not a good choice to use it >> for the application upgrades within the same repository type. You didn’t >> mention if your upgrade involves the repository migration (in this case >> choosing oak-upgrade would be justified) or not. >> >> If you still want to use oak-upgrade, it allows to use custom CommitHooks >> [1] during the migration. They should be included in the class path with >> the ServiceLoader mechanism [2]. >> >> Regards, >> Tomek >> >> [1] http://jackrabbit.apache.org/oak/docs/architecture/ >> nodestate.html#The_commit_hook_mechanism >> [2] https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html >> >> -- >> Tomek Rękawek | Adobe Research | www.adobe.com >> [email protected] >> >> > On 14 May 2017, at 12:20, Marco Piovesana <[email protected]> wrote: >> > >> > Hi all, >> > I'm trying to deal with backward-incompatible changes on my repository >> > structure. I was looking at the oak-upgrade module but, as far as I could >> > understand, I can't really make modifications that require some logic >> (e.g. >> > remove a property and add a new mandatory property with a value based on >> > the removed one). >> > I saw that one of the options might be the "namespace migration": >> > - remap the current namespace to a different prefix; >> > - create a new namespace with original prefix; >> > - port all nodes from old namespace to new namespace applying the >> required >> > modifications. >> > >> > I couldn't find much documentation on the topic, so my question is: is >> this >> > the right way to do it? There are other suggested approaches to the >> > problem? There's already a tool that can be used to define how to map a >> > source CND definition into a destination CND definition and then apply >> the >> > modifications to a repository? >> > >> > Marco. >>
