jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: The destiny of Oak (Was: [RESULT] [VOTE] Codename for the jr3 implementation effort)
Date Mon, 01 Oct 2012 14:56:56 GMT
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.

>
> 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
>>



Mime
View raw message