[rmi] JCR-RMI 2.0.0 release plan

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

Hi,

I'd like to start releasing individual JCR Commons components so we
can simplify the Jackrabbit core before the 1.6 release.

JCR-RMI is the component I've been using for setting up things in JCR
Commons. I think the component is getting close to being released by
itself, so I'd like anyone interested to give
jackrabbit/commons/jcr-rmi/trunk a quick look to check if everything
is OK. Note that (like the earlier versions), the component is a
proper OSGi bundle.

I'll still be making some build tweaks (enable the Maven GPG plugin,
etc.), but once I'm happy with all the details I plan to cut a
candidate for the JCR-RMI 2.0.0 release.

BR,

Jukka Zitting

Re: [rmi] JCR-RMI 2.0.0 release plan

[Felix Meschberger <fm...@gmail.com>]

Hi,

Jukka Zitting schrieb:
> Hi,
> 
> I had a quick chat with Angela about the versioning strategy, and she
> made a good point that calling the next release 2.0 will be confusing
> as we're not yet upgrading to JCR 2.0 or doing any other major changes
> to the codebase. Only the project structure is changing.
> 
> So, would it make more sense to call the next release JCR-RMI 1.6.0?

Works for me.


Regards
Felix

Re: [rmi] JCR-RMI 2.0.0 release plan

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

Hi,

I had a quick chat with Angela about the versioning strategy, and she
made a good point that calling the next release 2.0 will be confusing
as we're not yet upgrading to JCR 2.0 or doing any other major changes
to the codebase. Only the project structure is changing.

So, would it make more sense to call the next release JCR-RMI 1.6.0?

BR,

Jukka Zitting

Re: [rmi] JCR-RMI 2.0.0 release plan

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

Hi,

On Mon, Apr 6, 2009 at 7:50 PM, Felix Meschberger <fm...@gmail.com> wrote:
> I think, we probably don't need to export everything from this bundle
> (yet, testing this would be important). Rather we should probably export
> the most important factory classes: The Server and the Client factories
> and keep the rest private as implementation details. The factories
> should take care of getting the class loaders straight.

Is there a benefit to doing that? Most of the RMI layer is designed to
be extensible and customizable through subclassing, so hiding the
classes would seriously cut the options available to users.

> In addition, the bundle contains Jackrabbit-API and hence a Jackrabbit
> dependency, which is what we wanted to prevent IIRC. The problem is not,
> that this module is _using_ jackrabbit API but it is _implementing_
> jackrabbit API, and this makes it even more problematic, since this
> generates versioning issues (the imports must be more strict).

I'm not sure I follow you. Any decorator layer will both use and
implement an API, and I don't think that JCR-RMI is somehow special in
this respect. If the (decorated part of the) API changes, then the
decorator layer needs to be updated too.

I'm not enough of an OSGi expert to know whether or how that should be
reflected in the bundle metadata.

BR,

Jukka Zitting

Re: [rmi] JCR-RMI 2.0.0 release plan

[Felix Meschberger <fm...@gmail.com>]

Hi,

Good thing. I just checked it out and have a quick look at it. Here is a
first impression:

I think, we probably don't need to export everything from this bundle
(yet, testing this would be important). Rather we should probably export
the most important factory classes: The Server and the Client factories
and keep the rest private as implementation details. The factories
should take care of getting the class loaders straight.

In addition, the bundle contains Jackrabbit-API and hence a Jackrabbit
dependency, which is what we wanted to prevent IIRC. The problem is not,
that this module is _using_ jackrabbit API but it is _implementing_
jackrabbit API, and this makes it even more problematic, since this
generates versioning issues (the imports must be more strict).

WDYT ?

Regards
Felix

Jukka Zitting schrieb:
> Hi,
> 
> I'd like to start releasing individual JCR Commons components so we
> can simplify the Jackrabbit core before the 1.6 release.
> 
> JCR-RMI is the component I've been using for setting up things in JCR
> Commons. I think the component is getting close to being released by
> itself, so I'd like anyone interested to give
> jackrabbit/commons/jcr-rmi/trunk a quick look to check if everything
> is OK. Note that (like the earlier versions), the component is a
> proper OSGi bundle.
> 
> I'll still be making some build tweaks (enable the Maven GPG plugin,
> etc.), but once I'm happy with all the details I plan to cut a
> candidate for the JCR-RMI 2.0.0 release.
> 
> BR,
> 
> Jukka Zitting
>