hi jukka
1) The jackrabbit-jcr-commons package should contain generic utility classes that work *on top of* the JCR API. [...] Optimally the only dependencies should be the Java 1.4 and JCR 1.0 (later 2.0).
if i understand it properly this would include: - JcrConstants.java - value package: ValueFactoryImpl, Value implementations, ValueHelper.java - uuid package: since its used by the ValueFactory (not because i think this is really needed on top of the JCR API). - util package: Text.java, ISO8601.java, Base64.java, others? ->> see questions below. according the the description below the - org.apache.jackrabbit.name package would be moved to 2) or 3).
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.
> 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. that's what i would prefer. i think the conversion is general enough to be placed in a commons package as long as we can make sure, that it is not limited to a single name/path implementation. and i think SPI commons is a better place than jcr-commons due to the dependency to the SPI interfaces.
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.
agreed. this includes from my point of view: - the existing default implementations for > SPI identifier and factory > SPI value and factory > the various 'info' interfaces present in the SPI - in addition default implementations for > name (and factory) > path (and factory) and as stated above i would also include the - name/path conversion - value conversion
WDYT?
i'm in favour of this approach. kind regards angela open questions: - the spi-commons defines an alternative ValueFactoryImpl, that does not force the reference-value to be a UUID and which obviously does not belong to the spi-commons module. can we find a solution for this in the jcr-commons? - what about those util-classes that are used by a JCR-implementation but not by the SPI implementation? e.g. IteratorHelper.java Should those rather be in jcr-commons or in spi-commons? - what about general utility classes such as ISO9075.java, XMLChar.java, Timer.java that don't have any dependency to jackrabbit internals but still are not of general use on top of JCR? - what about the following packages in jackrabbit-jcr-commons: org.apache.jackrabbit.commons ? org.apache.jackrabbit.util.name ? are they used at all?
