Hi While (f-OSGi) has an appeal to me and think should be done in any case, I would think (g-separate) is the right way to go to prevent complexity with IMVHO little benefit.
Just my CHF 0.05 Regards Felix Am 15.01.2014 um 12:35 schrieb Jukka Zitting <[email protected]>: > 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
