On 10/01/2012 03:10 PM, Michael Dürig wrote: > > > On 1.10.12 12:36, Alexander Klimetschek wrote: >> On 01.10.2012, at 12:26, Jukka Zitting wrote: >> >>> 1) The Oak codebase will become Jackrabbit 3.0 sometime next year >> >>> 2) We spin off the Oak effort to a new Apache project >> >> I think 1) makes more sense given all the innovative work going into Oak. >> >> Keeping Jackrabbit 2.x in maintenance mode seems more feasible than separating >> Oak and Jackrabbit and possibly trying yet another approach to improve >> Jackrabbit. I doubt there are enough committers who would work on that. If >> 100% JCR spec compatibility is desired, it probably makes more sense to put >> the energy in extending oak-jcr to support that (with compromises etc.) rather >> then improving the existing Jackrabbit architecture. > > I second that. This would also send a strong signal regarding the intention of > the Oak effort. Furthermore it would reduce the fragmentation of the community > and keep efforts focused. +1 on this from me, so for option 1) The community isn't 'served' well IMO if a large part (most?) of the current Jackrabbit committers/developers would 'jump ship' and migrate over to Oak where the action then continues. I think and expect both the developers and (end) users involved to remain largely the same group anyway. So artificially splitting it up then doesn't make sense nor serve much purpose. > > Technically, since the functionality of Oak is largely based on the core > plugins, we could also identify sets of plugins for specific system behaviours. > So there could be a set of plugins for full JCR compliance (think JSR 170, 283, > 333) and probably other ones for embedded usage, small scale cluster usage, > large scale cluster usage and so on. Agreed, that sounds like a good and good enough solution to me. Ate > > Michael > >> >> Just my 2 cents, >> Alex >>