Hi, On Wed, Oct 21, 2009 at 9:30 AM, Angela Schreiber <[email protected]> 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
