jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Migration without an embedded Jackrabbit
Date Fri, 11 Oct 2013 14:28:01 GMT
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

Mime
View raw message