Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of mreutegg@adobe.com designates
 64.18.1.181 as permitted sender)
From: Marcel Reutegger <mreutegg@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Tue, 2 Oct 2012 09:56:05 +0100
Subject: RE: The destiny of Oak (Was: [RESULT] [VOTE] Codename for the jr3
 implementation effort)
Thread-Topic: The destiny of Oak (Was: [RESULT] [VOTE] Codename for the jr3
 implementation effort)
Thread-Index: Ac2fv2nF3JGM6t8UQG+WFKuQTn0brgAu0RWA
Message-ID: 
 <9C0FC4C8E9C29945B01766FC7F9D38981728708F18@eurmbx01.eur.adobe.com>
References: 
 <CAOFYJNb8mveux4OX_P_xb1Yj4BDeGq6gBHQPauh_SWnwKtqy-Q@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNb8mveux4OX_P_xb1Yj4BDeGq6gBHQPauh_SWnwKtqy-Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

my preference is something like 2), but with the JCR related components
moved to Jackrabbit. I'd like to see Oak as a hierarchical content reposito=
ry
implementation, but not necessarily as a JCR repository. The plugin mechani=
sm
in Oak was specifically designed for that purpose. Thus Jackrabbit 3 would
be oak-jcr plus plugins needed to turn a pure Oak repository into a JCR
repository. On the other hand Oak would mainly consist of the micro kernel
and oak-core and provide a robust and scalable basis for Jackrabbit 3 but
also other applications that directly speak to the Oak API.

Regards
 Marcel

> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Montag, 1. Oktober 2012 12:27
> To: Oak devs
> Subject: The destiny of Oak (Was: [RESULT] [VOTE] Codename for the jr3
> implementation effort)
>=20
> Hi,
>=20
> 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.
>=20
> As discussed last week in Berlin, with 6+ months since we started the
> Oak effort it's probably now time to revisit this issue.
>=20
> 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:
>=20
> 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.
>=20
> 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.
>=20
> WDYT?
>=20
> [1] When I asked, the early feedback from trademarks@apache.org about
> the "Oak" codename was that something like "Apache Oak" would likely
> be OK, but that we probably wouldn't be able to prevent anyone else
> from starting a competing "Oak" project. Not sure if that's a problem
> in practice.
>=20
> BR,
>=20
> Jukka Zitting