Hi I see the problem and I agree that this in fact *is* a problem.
But I still don't agree with an integrated, transparent solution to this upgrade problem. And I never will -- such application bloat and even code duplication along with testing and maintenance etc. requirements just sound scaring. Also: Code duplication is one of the big evils in application development. IMNSHO migration of Jackrabbit 2 based repositories to Oak is a one-shot problem: you apply this once to a repository and be done. So why load the application with a host of unneeded pieces ? Rather, I suggest to come up with a standalone application, which can be a conglomerate of original Jackrabbit and Oak libraries and which do the migration in one step. This application can be optimized and fine-tuned to just this single use-case: migration. This way, both Jackrabbit 2 and Oak applications stay clean of such migration junk. This also makes it clear that migration of storage from Jackrabbit2 to Oak is not something that can and will be done by just snipping your fingers, but which is a potentially long-running and complex operation. Regards Felix Am 11.10.2013 um 16:28 schrieb Jukka Zitting: > Hi, > > I've been thinking about the upgrade/migration code (oak-upgrade, > OAK-458) over the past few days, and trying to figure out how we could > achieve that without having to keep the full Jackrabbit 2.x codebase > as dependency. The same question comes up for the support for > Jackrabbit 2.x datastores (OAK-805). > > The key problem here is that the Jackrabbit 2.x codebase is already so > convoluted that it's practically impossible to just pick up say > something like an individual persistence manager or data store > implementation and access it directly without keeping the rest of the > 2.x codebase around. This is troublesome for many reasons, for example > using such components require lots of extra setup code (essentially a > full RepositoryImpl instance) and the size of the required extra > dependencies is about a dozen megabytes. > > Thus I'm inclined to instead just implement the equivalent > functionality directly in Oak. This requires some code duplication > (we'd for example need the same persistence managers in both Oak and > Jackrabbit), but the versions in Oak could be a lot simpler and more > streamlined as only a subset of the functionality is needed. To reduce > the amount of duplication we could push some of the shared utility > code (like NodePropBundle, etc.) to jackrabbit-jcr-commons or to a new > jackrabbit-shared component. > > WDYT? > > BR, > > Jukka Zitting
smime.p7s
Description: S/MIME cryptographic signature
