Hi Jukka, I think the situation is slightly different between OAK-458 and OAK-805 (although I come to roughly the same conclusion in both cases)
OAK-805: JR users that cannot upgrade their existing data store will be stuck "eternally" after a migration (I think it is fair to assume and a reasonable deployment case that a large amount of binaries might not be feasible to move ever). So, in turn this means that we would be eternally stuck with all the mentioned JR dependencies in Oak unless we re-implement the existing functionality. However, it also means, that this re-implementation needs to be "production quality" for read/write (as opposed to the second case). So, I think a re-implmentation makes sense. OAK-458: In this case the functionality that needs to be re-implemented is certainly a subset, as it requires only read-access to the repo (and does not need to cover a lot of edge cases that a full fledged read-write support needs to cover). So, I am inclined to also opt for a re-implementation if this subset is sufficiently easy to implement. If not, we could pull in the whole enchilada of dependencies as we know that we can drop them later: IMO it would be fair to drop (or make optional) the ability to upgrade an existing JR repo to Oak at a certain point in the future and thus remove the additionally needed deps. Michael On Oct 11, 2013, at 4:28 PM, Jukka Zitting wrote: 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
