hi jukka

On 8/8/07, Jukka Zitting <[EMAIL PROTECTED]> 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

cheers
stefan

>
> BR,
>
> Jukka Zitting
>

Reply via email to