jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Migration without an embedded Jackrabbit
Date Mon, 14 Oct 2013 08:38:48 GMT

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.


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.
> BR,
> Jukka Zitting

View raw message