jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: JCR 2.0 extensions
Date Wed, 08 Aug 2007 09:23:53 GMT
hi jukka

On 8/8/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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.

i agree, +1


> BR,
> Jukka Zitting

View raw message