Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.132.246 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=DNfxbjQoYuavZNxTvYP2Ki9K+vQqL9tsulIJyQOFUDupP2U/bSoZYoyJHuEuRzXVW6mnTDYOb6JWfJeAmfluxx/5Df5ZXF7uTpcBt2pfEKMRG6IG7tnoRBnMV+O+VO8O8ZKTdob9KLJRvN1dUX/CDNql+fCI965tHqa1EWDSkOo=
Message-ID: <510143ac0707260252o2a6743bcn5445c6611cfad789@mail.gmail.com>
Date: Thu, 26 Jul 2007 12:52:09 +0300
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Distribution of commons classes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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