Hi Marco In this case I think you should use the JCR API to implement your content changes.
I am not aware of a pure JCR toolkit that helps with this, so you may just need to write something yourself. Regards Julian On Fri, May 19, 2017 at 5:00 PM, Marco Piovesana <pioves...@esteco.com> wrote: > Hi Julian, > I meant I'm using Oak not Sing. Yes I'm using JCR API. > > Marco. > > On Fri, May 19, 2017 at 2:22 PM, Julian Sedding <jsedd...@gmail.com> wrote: > >> Hi Marco >> >> On Fri, May 19, 2017 at 2:10 PM, Marco Piovesana <pioves...@esteco.com> >> wrote: >> > Hi Julian, Michael and Robert >> > first of all thanks for the suggestions. >> > I'm using Oak directly inside my application, >> >> Do you mean you are not using the JCR API? >> >> > so I guess the Sling Pipes >> > are not something I can use, or not? Is the concept of Pipe already >> defined >> > in some way inside oak? >> >> No Oak has no such concept. Sling Pipes is an OSGi bundle that is >> unrelated to Oak but uses the JCR and Jackrabbit APIs (both are >> implemented by Oak). >> >> Regards >> Julian >> >> > >> > Marco. >> > >> > On Fri, May 19, 2017 at 10:39 AM, Julian Sedding <jsedd...@gmail.com> >> wrote: >> > >> >> Hi Marco >> >> >> >> It sounds like you are dealing with a JCR-based application and thus >> >> you should be using the JCR API (directly or indirectly, e.g. via >> >> Sling) to change your content. >> >> >> >> CommitHook is an Oak internal API that does not enforce any JCR >> >> semantics. So if you were to go down that route, you would need to be >> >> very careful not to change the content structure in a way that >> >> essentially corrupts JCR semantics. >> >> >> >> Regards >> >> Julian >> >> >> >> >> >> On Tue, May 16, 2017 at 6:33 PM, Marco Piovesana <pioves...@esteco.com> >> >> 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 >> <reka...@adobe.com.invalid >> >> > >> >> > 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 >> >> >> reka...@adobe.com >> >> >> >> >> >> > On 14 May 2017, at 12:20, Marco Piovesana <pioves...@esteco.com> >> >> 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. >> >> >> >> >> >> > > > > -- > > marco piovesanA > Enterprise Application > > > > *ESTECO* | EXPLORE DESIGN PERFECTION > > AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY > Phone: +39 040 3755548 - Fax: +39 040 3755549 > [Website] <http://www.esteco.com> | [Twitter] > <https://twitter.com/esteco_mF> | [Facebook] > <https://www.facebook.com/esteco.spa> | [Linkedin] > <https://www.linkedin.com/company/748217> > Pursuant to Legislative Decree No. 196/2003, you are hereby informed that > this message contains confidential information intended only for the use of > the addressee. If you are not the addressee, and have received this message > by mistake, please delete it and immediately notify us. You may not copy or > disseminate this message to anyone. Thank you. Please consider the > environment before printing this email.
