Hi, Let's pick this up again!
On Thu, Jan 17, 2013 at 6:00 AM, Jukka Zitting <[email protected]> wrote: >> * Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have >> been created, we'd replace the current trunk with an Oak-based JCR >> implementation. > > As mentioned above, instead of replacing the trunk entirely, I'd keep > both codebases in trunk for now and include *both* the 2.x and Oak > repositories in things like jackrabbit-webapp and > jackrabbit-standalone, with a configuration option to decide which > repository implementation should be used in each particular > deployment. I was looking at this a few months ago, and there's one big blocker that makes such a double deployment somewhat complicated: Since Jackrabbit 2.x ("Jackrabbit Classic"?) still uses an older version of Lucene, it's hard merge with Oak where Lucene 4 is used. I have a few ideas on how this problem could be resolved: a) Upgrade Jackrabbit Classic to use Lucene 4. As discussed earlier (http://markmail.org/message/nv5jeeoda7qe5qen) this is pretty hard, and it's questionable whether the benefits are worth the effort. b) Downgrade Oak to use Lucene 3. This should be doable with not much effort, as the Lucene integration in Oak is much simpler than in Jackrabbit Classic. It might even be possible to make oak-lucene version-independent, so it would work with both Lucene 3 and 4. c) Ship the jackrabbit deployment packages without Lucene integration for Oak. This would allow people to start playing with Oak in their existing deployments, but require some deployment changes for full Oak functionality. d) Use the class rewriting tricks in something like the Shade plugin [1] to be able to include both Lucene 3 *and* 4 in the same deployment packages. I'm not sure if this is even possible with Lucene, or how much effort it would require. e) Use a custom classloader setup to load the correct version of Lucene depending on the selected Jackrabbit mode. f) Adjust the Jackrabbit deployment packages to use an embedded OSGi container, and use it to selectively deploy the required implementation components, including the correct version of Lucene. g) Or as a last resort, abandon the idea of a joint deployment package. Jackrabbit Classic and Oak would be shipped in separate deployment artifacts. I'm thinking of trying to implement one or two of these alternatives within the next few weeks, and cut Jackrabbit 2.8 based on that work and including something like Oak 0.16 as a beta feature. Assuming that approach works and Oak stabilizes as planned, we could then follow up with Jackrabbit 3.0 fairly soon after 2.8. [1] http://maven.apache.org/plugins/maven-shade-plugin/ BR, Jukka Zitting
