jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Distribution of commons classes
Date Thu, 26 Jul 2007 10:10:58 GMT
On 7/26/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> With JCR-996 and the goal of eventually integrating SPI with
> Jackrabbit core there comes a question of where and how we should
> bundle the various "commons" classes we have. Currently
> jackrabbit-jcr-commons is the throw-in default of all utility classes
> that might be useful also outside jackrabbit-core.
> To better define the scope of jackrabbit-jcr-commons and related
> packages, I'd like to propose the following:
> 1) The jackrabbit-jcr-commons package should contain generic utility
> classes that work *on top of* the JCR API. The classes should handle
> names and paths in string format, and use the namespace methods on
> javax.jcr.Session where name manipulation is needed. The package can
> also contain JCR base classes and other utilities that implement JCR
> interfaces and methods in terms of other JCR API calls. Optimally the
> only dependencies should be the Java 1.4 and JCR 1.0 (later 2.0).
> 2) The jackrabbit-jcr2spi package should contain everything that is
> needed to bridge between the JCR and SPI interfaces. Optimally the
> only dependencies would be Java 1.4, JCR 1.0 (later 2.0), SPI, and
> possibly jackrabbit-jcr-commons and other generic things like
> commons-collections and slf4j. Note that much of the functionality in
> jackrabbit-jcr2spi should be usable as a generic dependency also for
> "native" transient space implementations like the current
> jackrabbit-core.
> 3) The jacrabbit-spi-commons package should contain generic utility
> classes that work *below* the SPI. Optimally the only dependencies
> would be Java 1.4 and SPI. This package should be usable by both
> jackrabbit-core and any SPI-based JCR connectors.
> I would optimally place all the string-name conversion functionality
> in jcr2spi, but since at least the query parser needs that
> functionality on the SPI implementation side, it might be necessary to
> push that functionality down to spi-commons.

+1, sounds good.


> BR,
> Jukka Zitting

View raw message