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 <jukka.zitt...@gmail.com> 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
