jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bart van der Schans <b.vandersch...@onehippo.com>
Subject Re: The destiny of Oak (Was: [RESULT] [VOTE] Codename for the jr3 implementation effort)
Date Mon, 01 Oct 2012 15:19:17 GMT
On Mon, Oct 1, 2012 at 4:56 PM, Ate Douma <ate@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.zitting@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.


View raw message