Re: Distribution of commons classes

[Angela Schreiber <an...@day.com>]

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?