Merging jcr2spi and spi2jcr to spi-commons

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

Hi,

I was looking at ways to simplify the dependency set for SPI
implementations, and started thinking of why we really do need to have
jcr2spi and spi2jcr in separate components. They're obviously
architecturally different, but they share essentially the same
dependencies and will both need to be updated whenever the SPI
interfaces change. We don't even test them separately. Managing them
as a single unit with a single version number would be easier.

I propose that we take both the jcr2spi and spi2jcr codebases and
merge them to the spi-commons component that also has the same set of
dependencies and is tightly related to both of the two components.

The downside of such a merge is that some deployment scenarios (a
jcr2spi + spi2dav client for example) will end up with some unused
classes in the classpath, but that's already the case with
dependencies like commons-collections.

Are there some points that I'm missing?

BR,

Jukka Zitting

Re: Merging jcr2spi and spi2jcr to spi-commons

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

Hi,

Jukka Zitting schrieb:
> Hi,
> 
> On Wed, Oct 21, 2009 at 9:30 AM, Angela Schreiber <an...@day.com> wrote:
>>> This would support the long term goal of getting rid of the separate
>>> transient space implementations in core and jcr2spi, as it would be
>>> easier for core to reuse stuff from jcr2spi.
>> if this is the aim of the whole execise then i don't see
>> why we have to do this right now... i don't know of any
>> plans to have core reusing jcr2spi stuff.
> 
> My main aim is to simplify the deployment of SPI connectors like
> spi2dav (see the related thread on remoting and JCR-RMI). Having
> jcr2spi included in spi-commons would remove one extra dependency from
> client projects and would allow spi2dav to include a
> javax.jcr.RepositoryFactory implementation.

Well, honestly. The problem is not the dependency per-se but lack of
documentation thereof !

I tend to agree with Angela that we should not merge projects/libraries
just to make it "easier" for one use case... I think keeping the thing
architecturally clean is way better -- and easier to use in the long term.

Regards
Felix

> 
>> jcr2spi currently is a half-way jsr 283 implementation as
>> we are short of resources and fixing access control,
>> rentention management, shareable nodes etc. for the
>> jcr2spi doesn't have any prio. i don't see how you want
>> to merge that with the core.
> 
> I have no immediate needs on that front in mind. But having the
> jcr2spi code included in spi-commons will make it easier to move
> forward on this front in the future if or when we have more resources
> for that.
> 
>> and last but not least:
>> i don't see any reason why we have to discuss this
>> right now. michi is on vacation and i'm kind of busy
>> with the next CQ release... honestly i don't have leisure
>> time to think about things that i consider not to be
>> crucial for the overall functionality.
>>
>> can we please postpone this discussion?
> 
> No problem, but I'd like to see a resolution (either way) on this
> before Jackrabbit 2.0 is final.
> 
> I brought this up now since I ran into this issue when looking at ways
> to simplify DAVex clients, which will be fairly important especially
> if we decide to drop JCR-RMI.
> 
> BR,
> 
> Jukka Zitting
> 

Re: Merging jcr2spi and spi2jcr to spi-commons

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

Hi,

On Wed, Oct 21, 2009 at 9:30 AM, Angela Schreiber <an...@day.com> wrote:
>> This would support the long term goal of getting rid of the separate
>> transient space implementations in core and jcr2spi, as it would be
>> easier for core to reuse stuff from jcr2spi.
>
> if this is the aim of the whole execise then i don't see
> why we have to do this right now... i don't know of any
> plans to have core reusing jcr2spi stuff.

My main aim is to simplify the deployment of SPI connectors like
spi2dav (see the related thread on remoting and JCR-RMI). Having
jcr2spi included in spi-commons would remove one extra dependency from
client projects and would allow spi2dav to include a
javax.jcr.RepositoryFactory implementation.

> jcr2spi currently is a half-way jsr 283 implementation as
> we are short of resources and fixing access control,
> rentention management, shareable nodes etc. for the
> jcr2spi doesn't have any prio. i don't see how you want
> to merge that with the core.

I have no immediate needs on that front in mind. But having the
jcr2spi code included in spi-commons will make it easier to move
forward on this front in the future if or when we have more resources
for that.

> and last but not least:
> i don't see any reason why we have to discuss this
> right now. michi is on vacation and i'm kind of busy
> with the next CQ release... honestly i don't have leisure
> time to think about things that i consider not to be
> crucial for the overall functionality.
>
> can we please postpone this discussion?

No problem, but I'd like to see a resolution (either way) on this
before Jackrabbit 2.0 is final.

I brought this up now since I ran into this issue when looking at ways
to simplify DAVex clients, which will be fairly important especially
if we decide to drop JCR-RMI.

BR,

Jukka Zitting

Re: Merging jcr2spi and spi2jcr to spi-commons

[Angela Schreiber <an...@day.com>]

hi jukka

> How about an alternative of merging just jcr2spi to spi-commons and
> leaving spi2jcr as a separate component like spi2dav?

hm... i don't like it.

> This would support the long term goal of getting rid of the separate
> transient space implementations in core and jcr2spi, as it would be
> easier for core to reuse stuff from jcr2spi.

if this is the aim of the whole execise then i don't see
why we have to do this right now... i don't know of any
plans to have core reusing jcr2spi stuff.

jcr2spi currently is a half-way jsr 283 implementation as
we are short of resources and fixing access control,
rentention management, shareable nodes etc. for the
jcr2spi doesn't have any prio. i don't see how you want
to merge that with the core.

and last but not least:
i don't see any reason why we have to discuss this
right now. michi is on vacation and i'm kind of busy
with the next CQ release... honestly i don't have leisure
time to think about things that i consider not to be
crucial for the overall functionality.

can we please postpone this discussion?

regards
angela

Re: Merging jcr2spi and spi2jcr to spi-commons

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

Hi,

On Tue, Oct 20, 2009 at 5:40 PM, Angela Schreiber <an...@day.com> wrote:
> i wouldn't be in favor of such a move.

How about an alternative of merging just jcr2spi to spi-commons and
leaving spi2jcr as a separate component like spi2dav?

This would support the long term goal of getting rid of the separate
transient space implementations in core and jcr2spi, as it would be
easier for core to reuse stuff from jcr2spi.

And in other cases; a spi2something client needs both spi-commons and
jcr2spi for JCR API access to the SPI backend. Having them as a single
dependency would simplify things and even allow the spi2something jar
to contain a RepositoryFactory (and Repository) class that clients can
use directly without needing a yet another dependency like jcr-client.

BR,

Jukka Zitting

Re: Merging jcr2spi and spi2jcr to spi-commons

[Angela Schreiber <an...@day.com>]

hi jukka

i think this would be wrong from a conceptual point of view.

- jcr2spi is a JCR implementation
- spi2jcr is an example implementation of the SPI that we
   mainly used for developing jcr2spi as it was straight forward
   to implement having a jackrabbit-core as jcr-part in spi2jcr.
- spi-commons is a container for utility and default-implementations
   of the SPI interfaces similar to jcr-commons for JCR interfaces.
   this is really internal stuff.

then:
jackrabbit-core has a dependency to the spi-commons as
well as since jackrabbit-jcr2spi and jackrabbit-core
share some of the internal logic such as namespace,
name, path and node type handling.
but jackrabbit-core hasn't too much to do with jcr2spi or
spi2jcr. i mean: nothing.

long time ago we had the jcr-commons stuff being part
of jackrabbit-core and we decided to put that into a
separate module. merging jcr2spi or spi2jcr with the spi-commons
would take the contrary approach and looks wired to me.

i wouldn't be in favor of such a move.

regards
angela