Hi, I second Felix' comments and prefer a standalone upgrade tool. this does not mean that an upgrade is always a manual step. the embedding application (e.g. Sling) can still contain the tool and auto-upgrade if desired.
I even think that a migration could be done purely on the JCR level, for example using vlt rcp (which does not support copying versions, but this could be improved). This specially might be useful, if the migration also includes some more complex reconfiguration, e.g. setup a highly clustered environment or special datastores. Regards, Toby On Mon, Oct 14, 2013 at 6:46 AM, Jukka Zitting <[email protected]<mailto:[email protected]>> wrote: Hi, On Mon, Oct 14, 2013 at 9:09 AM, Felix Meschberger <[email protected]<mailto:[email protected]>> wrote: > Thanks for the clarifications. Yet, they more confirm my first impression > than they resolve the concerns. > > Particularly your timing and smoothness assumptions. Migrating JR2 to Oak is > much more complex > than migrating from one version of JR2 to the next. I would even assume it is > way more complex > than migrating from JR1 to JR2. Yes, that's definitely true. As for the timing assumptions, based on rough estimates I'm expecting that a fairly large (i.e. millions of nodes) repository could be upgraded in minutes with custom upgrade code vs. hours with standard Jackrabbit components. Definitely not as smooth or fast as past Jackrabbit upgrades, but still reasonable and IMO worth the overhead. > So, let's agree to disagree ;-) Thanks for sharing your concerns! Unless others also weigh in on the side of a separate upgrade tool, I think for now I'd still give a go for the proposed custom/duplicate code. But I'll keep an eye on the amount of extra complexity, and as Michael noted, fall back to the separate tool if the amount of duplication/overhead seems to start becoming unmanageable. The PMs in Jackrabbit are now at 15kLOC, so my warning bells would start ringing at around 2kLOC of extra code for PM upgrades. BR, Jukka Zitting
