Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.132.250 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=Xebyio0dtWEsXO0m1yeuPbuqyMiZC4g1oDOUuS4WbI93+CThpNzQynHR6ASAKs5CdCKyWI15iV7zBb+DC6MYJ91HRZQfQSXnF44xTHQwVTQyIy7u99PKFzbkHAfsOZo/kGLtSB3NlDYsLPBF3Z5B3PmYUvlVl6FwRI81p62gmRI=
Message-ID: <510143ac0708080206n15b6715bq44eecde6aeb04937@mail.gmail.com>
Date: Wed, 8 Aug 2007 12:06:37 +0300
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: dev@jackrabbit.apache.org
Subject: JCR 2.0 extensions
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

Now that the public review draft of JCR 2.0 is available we can start
implementing the changes and new features. We need to do this already
now for Jackrabbit to be ready for use as the JCR 2.0 reference
implementation when the standard becomes final.

The difficult part in implementing the JCR 2.0 features is that things
may still change before the spec is finalized. Also, we don't have any
official jcr-2.0 API jar file and we can't go extending the existing
JCR 1.0 javax.jcr interfaces without serious breakage. So, to
implement the new features we need to use some "staging area" for the
new interfaces and methods being introduced in JCR 2.0.

One option would be to use the existing jackrabbit-api package and add
the JCR 2.0 extensions as custom org.apache.jackrabbit.api extensions.
This may however cause trouble later on as we should maintain
reasonable backwards compatiblity with any additions to jackrabbit-api
even if JCR 2.0 ends up being different.

To best manage the change I would like to start a separate
jackrabbit-jsr283 component that would contain tentative JCR 2.0
extension interfaces in org.apache.jackrabbit.jsr283. We wouldn't need
to make any backwards compatibility claims for that component, but any
other components like jackrabbit-core, jackrabbit-jcr-tests,
jackrabbit-jcr-rmi, and jackrabbit-jcr2spi could depend on that
component until the final jcr-2.0.jar is available.

What do you think? I guess there is some licensing stuff to figure
out, but otherwise I think this would be the cleanest approach.

BR,

Jukka Zitting