On Mon, Oct 1, 2012 at 4:56 PM, Ate Douma <a...@douma.nu> wrote: > 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.
My preference also goes to option 1. I agree with the things said before. Having two JCR implementations at Apache with two communities feels a little bit odd to me. It might confuse developers starting with JCR as well. In the end we want everybody to use/move to Jackrabbit 3/Oak and contribute to that effort rather than try to improve (the perfomance of) Jackrabbit 2 which probably would require rewriting large portions of code. Regards, Bart
