jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@apache.org>
Subject Re: The destiny of Oak (Was: [RESULT] [VOTE] Codename for the jr3 implementation effort)
Date Mon, 01 Oct 2012 15:18:03 GMT
On Mon, Oct 1, 2012 at 12:26 PM, Jukka Zitting <jukka.zitting@gmail.com>wrote:

> Hi,
> On Tue, Mar 6, 2012 at 9:17 AM, Jukka Zitting <jukka.zitting@gmail.com>
> wrote:
> > As discussed earlier and mentioned again by Roy, the Oak name is a bit
> > troublesome for more general branding, which reinforces the point that
> > we'll use it as a codename for the development effort and decide later
> > on whether to brand the result as "Jackrabbit 3" or something else.
> As discussed last week in Berlin, with 6+ months since we started the
> Oak effort it's probably now time to revisit this issue.
> Basically the question is about how we want to brand and manage the
> Oak effort going forward. It looks like we have two main alternatives
> to choose from:
> 1) The Oak codebase will become Jackrabbit 3.0 sometime next year
> replacing the current Jackrabbit trunk, and the Oak codename will
> gradually be dropped. Current Jackrabbit trunk will move to a separate
> 2.x branch where it will remain in maintenance mode until everyone has
> had a chance to migrate to Jackrabbit 3.x. Jackrabbit 3.0 will no
> longer strive to be a "fully conforming" reference implementation of
> JCR.
> 2) We spin off the Oak effort to a new Apache project (Apache Oak, or
> something else [1]) with its own goals and community; of course with a
> high priority to make migration from Jackrabbit as easy as possible.
> Jackrabbit will remain the "fully conforming" JCR implementation, with
> Jackrabbit 3.0 most likely becoming the reference implementation of
> JSR 333. Over time the focus of Jackrabbit may shift to become more of
> a JCR "commons" place where people collaborate on things like the JCR
> remoting layers, OCM, the test suite, and of course the reference
> implementation.
For me the question largely comes down to whether there is a market for
both projects independent of each other. Whether when Oak has matured
enough, Jackrabbit 2 will be phased out or that, independent of Oak, a
reference implementation of the JCR specification that strives for maximum
compliancy is still viable. Personally I think not, and therefore I am
leaning towards Oak as Jackrabbit 3.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message