Hi, On Mon, Oct 14, 2013 at 1:20 PM, Tobias Bocanegra <tri...@adobe.com> wrote: > 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.
After some more work on this, I'm actually inclined to go with a hybrid solution somewhat along those lines. I'd implement a custom code for simple upgrades (default Jackrabbit configuration, etc.) that can reasonably be done transparently without extra user action or with any of the extra Jackrabbit dependencies, but fall back to a separate upgrade tool with standard Jackrabbit components for more complex cases and situations where the user in any case wants full control over the upgrade. This should be reasonably straightforward to implement without much code duplication. For now I've added a simple "ugprade" mode to oak-run as an initial take on such a separate upgrade tool. I even think I have a solution that allows me to avoid having to embed all the Jackrabbit dependencies in an OSGi environment. Basically I'd define a few simplified extension interfaces in oak-upgrade for things like Jackrabbit persistence managers and other required internals, and Jackrabbit bundles installed in the same OSGi container can offer the required implementations for those interfaces. > 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). Right. Something like that would ultimately be quite nice, as it would give us an implementation-independent way to backup and restore entire repositories, a bit like the dump features in many SQL databases work. Though getting to that point will probably require quite a bit of work (including API extensions required for version support, etc.), and it will probably never reach similar performance as a direct lower-level upgrade can. BR, Jukka Zitting
