jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Merging jcr2spi and spi2jcr to spi-commons
Date Wed, 21 Oct 2009 10:46:26 GMT

Jukka Zitting schrieb:
> Hi,
> On Wed, Oct 21, 2009 at 9:30 AM, Angela Schreiber <anchela@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.


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

View raw message