JCR 2.0 extensions

[Jukka Zitting <ju...@gmail.com>]

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

Re: JCR 2.0 extensions

[Thomas Mueller <th...@gmail.com>]

Hi,

> so we would probably try to postpone any work that would
> require the api change (which in my mind is very little) to
> the latest point in time possible.

Maybe there is a time where you want to support both APIs. But that's
probably not as important as for JDBC, where the API version is bound
to the JDK.

> adding a return value ... does not break existing code

Not user code. But it does break JCR implementations (Jackrabbit for example).

> harmless and suitable for a 2.0 release.

It is not unproblematic, but the advantages to change are probably
higher than the disadvantages. In the JDBC API such changes were never
be made. It was always adding more methods and classes, never adding
thrown exceptions to methods or changing the return value.

Thomas

Re: JCR 2.0 extensions

[David Nuescheler <da...@day.com>]

hi thomas,

> > But since jsr283 should be mainly backwards compatible
> It's not. Some methods now return something that didn't before.
as christoph mentioned i think those are in relatively isolated places
so we would probably try to postpone any work that would
require the api change (which in my mind is very little) to
the latest point in time possible.

> > In case we do ran up with compatibility issues,
> > I think we have a good case to request a change in JSR 283.
> Maybe making the JSR 283 API backwards compatible is the best solution.
that would be ideal.
but since there are some obvious corrections needed, we would like to
make those fixes as soon as possible.
particularly, the example of adding a return value that you mention
above does not break existing code, therefore i consider it relatively
harmless and suitable for a 2.0 release.

regards,
david

Re: JCR 2.0 extensions

[Thomas Mueller <th...@gmail.com>]

Hi,

org.apache.jackrabbit.jsr283 is a good idea. In a new component, or in
jackrabbit-api.

> But since jsr283 should be mainly backwards compatible

It's not. Some methods now return something that didn't before.

> In case we do ran up with compatibility issues,
> I think we have a good case to request a change in JSR 283.

Maybe making the JSR 283 API backwards compatible is the best solution.

If this is not done, one solution is to use wrapper classes for both
JCR 1.0 and JCR 2.0. Another solution: 'switch' the code to one or the
other API by automatically 'remarking out' (filtering) the 'wrong'
method.

Thomas

Re: JCR 2.0 extensions

[Christoph Kiehl <ch...@sulu3000.de>]

Julian Reschke wrote:
> Jukka Zitting wrote:
>> On 8/8/07, Christoph Kiehl <ch...@sulu3000.de> wrote:
>>> Sounds good. We just need to make sure that those jsr283 interfaces 
>>> do not
>>> interfere with jsr170 interfaces because some Jackrabbit classes will 
>>> need to
>>> implement both interfaces. But since jsr283 should be mainly backwards
>>> compatible this shouldn't be a problem.
>>
>> Yep. In case we do ran up with compatibility issues, I think we have a
>> good case to request a change in JSR 283.
> 
> As far as I recall, we have at least one method signature that changed 
> with respect to throwing exceptions...

May be can we skip that method as long as possible if it's going to be a problem.

>>> Or do you want to start a whole new branch where all jsr170 interfaces
>>> are replaced by jsr283 interfaces?
>>
>> We need to do that eventually, but I'd very much like to push the
>> branch point as far ahead as possible to avoid getting stuck with two
>> parallel actively developed codebases. Ideally we'd release 1.4 and
>> perhaps even 1.5 with early JCR 2.0 features included before dropping
>> JCR 1.0 from svn trunk and focusing on the real JCR 2.0 interfaces for
>> the Jackrabbit 2.0 release.
> 
> +1

I completely agree. I was in no means in favor of creating a branch as long as 
it could be avoided.

Cheers,
Christoph

Re: JCR 2.0 extensions

[Julian Reschke <ju...@gmx.de>]

Jukka Zitting wrote:
> On 8/8/07, Christoph Kiehl <ch...@sulu3000.de> wrote:
>> Sounds good. We just need to make sure that those jsr283 interfaces do not
>> interfere with jsr170 interfaces because some Jackrabbit classes will need to
>> implement both interfaces. But since jsr283 should be mainly backwards
>> compatible this shouldn't be a problem.
> 
> Yep. In case we do ran up with compatibility issues, I think we have a
> good case to request a change in JSR 283.

As far as I recall, we have at least one method signature that changed 
with respect to throwing exceptions...

>> Or do you want to start a whole new branch where all jsr170 interfaces
>> are replaced by jsr283 interfaces?
> 
> We need to do that eventually, but I'd very much like to push the
> branch point as far ahead as possible to avoid getting stuck with two
> parallel actively developed codebases. Ideally we'd release 1.4 and
> perhaps even 1.5 with early JCR 2.0 features included before dropping
> JCR 1.0 from svn trunk and focusing on the real JCR 2.0 interfaces for
> the Jackrabbit 2.0 release.

+1

Best regards, Julian

Re: JCR 2.0 extensions

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 8/8/07, Christoph Kiehl <ch...@sulu3000.de> wrote:
> Sounds good. We just need to make sure that those jsr283 interfaces do not
> interfere with jsr170 interfaces because some Jackrabbit classes will need to
> implement both interfaces. But since jsr283 should be mainly backwards
> compatible this shouldn't be a problem.

Yep. In case we do ran up with compatibility issues, I think we have a
good case to request a change in JSR 283.

> Or do you want to start a whole new branch where all jsr170 interfaces
> are replaced by jsr283 interfaces?

We need to do that eventually, but I'd very much like to push the
branch point as far ahead as possible to avoid getting stuck with two
parallel actively developed codebases. Ideally we'd release 1.4 and
perhaps even 1.5 with early JCR 2.0 features included before dropping
JCR 1.0 from svn trunk and focusing on the real JCR 2.0 interfaces for
the Jackrabbit 2.0 release.

BR,

Jukka Zitting

Re: JCR 2.0 extensions

[Christoph Kiehl <ch...@sulu3000.de>]

Jukka Zitting wrote:

> 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.

Sounds good. We just need to make sure that those jsr283 interfaces do not 
interfere with jsr170 interfaces because some Jackrabbit classes will need to 
implement both interfaces. But since jsr283 should be mainly backwards 
compatible this shouldn't be a problem. Or do you want to start a whole new 
branch where all jsr170 interfaces are replaced by jsr283 interfaces?

Cheers,
Christoph

Re: JCR 2.0 extensions

[Julian Reschke <ju...@gmx.de>]

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

Sounds exactly right to me.

Best regards, Julian

Re: JCR 2.0 extensions

[Stefan Guggisberg <st...@gmail.com>]

hi jukka

On 8/8/07, Jukka Zitting <ju...@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

cheers
stefan

>
> BR,
>
> Jukka Zitting
>