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. WDYT? BR, Jukka Zitting
