jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting ...@yukatan.fi>
Subject Re: common libraries for jcr and jackrabbit
Date Thu, 19 May 2005 10:46:30 GMT
Hi,

Tobias Strasser wrote:
> as discussed in other threads, there is a need for commons or helper
> libraries, containing either JCR related or Jackrabbit related stuff.

I agree. I've been doing some work related to this need in my JCR-EXT 
contrib package, but so far my goal has been to build a common ground 
mostly for lightweight JCR adapters for existing content repositories 
instead of making the classes useful for full-blown JCR implementations 
like Jackrabbit.

Below is a summary of the existing stuff I have in JCR-EXT. I'd be happy 
to repurpose this code as a more general purpose JCR commons library, 
but creating another commons package that is more directly linked with 
the needs of Jackrabbit might fit the needs better.

So far I haven't been in a too much hurry to document these packages and 
classes as I've been the only one using them, but if there's general 
interest in using them more widely, I'll put more focus on documentation.

org.apache.jackrabbit.name
   Classes for handling qualified names and paths. Simplified versions
   of the Jackrabbit core classes without the Jackrabbit dependencies
   (NamespaceResolver etc.)

org.apache.jackrabbit.iterator
   Simple array-based implementations of the JCR RangeIterator
   interfaces.

org.apache.jackrabbit.base
   General base classes for the JCR interfaces. Useful for default
   implementations of methods like Property.getString() (implemented
   as Property.getValue().getString()).

org.apache.jackrabbit.decorator
   Simple attempt at a general decorator layer for the JCR API.
   Not ready for use.

org.apache.jackrabbit.xml
   Partial implementations of the XML import and export functionality.
   Not ready for use.

org.apache.jackrabbit.session
   Currently a simple implementation of the NodeType API and the Session
   namespace handling functionality. The goal for this package is to
   provide simple implementations for most of the Session-related parts
   (anything that uses qualified names!) of the JCR API

org.apache.jackrabbit.state
   Backend classes for handling the internal state accessible through the
   o.a.j.session classes.

Note: The package names are not cast in stone. My original idea was to 
use a org.apache.jackrabbit.ext prefix for the packages, but it was 
suggested that I avoid using too deep namespaces and that we should 
discuss the namespace structure on the list if collisions occur. I think 
now might be a good time for this namespace discussion. :-)

> for example most of the Value stuff could now be swaped out to a
> common jcr helpers lib. further some escaping, formatting and
> serializing stuff. The problem is that a lot of those depend on
> internal jackrabbit classes like QName, Path and UUID. so those would
> also need to go into the common jackrabbit lib.

If that happens, the dependent classes will probably need some 
refactoring as well. When I started building the Midgard-JCR adapter I 
first thought about using the Jackrabbit core classes to bootstrap the 
project, but I soon noticed that without some changes they would bring 
too much of Jackrabbit with them as dependencies. Thus I decided to 
build my own versions in the JCR-EXT package.

> - what is the general feeling about this?

I think this is a good idea. If we don't want to repurpose JCR-EXT for 
this, then I'll most probably make the new commons library a dependency 
for JCR-EXT and set a clearer focus for JCR-EXT by contributing the 
general purpose code into the commons library.

> - is it ok for jackrabbit core to depend on commons-jackrabbit and commons-jcr ?

I think the only problem would be in finding the correct interface 
between the packages. The commons package should be generic enough to be 
useful in other projects while still providing all the functionality 
(and performance!) required by Jackrabbit.

> - how should the maven projects look like?

I think the commons project should be an independent contrib (or 
whatever) subproject, with as little external dependencies as possible. 
We could make separate releases of the commons project and treat is as a 
normal Maven dependency in the Jackrabbit core.

BR,

Jukka Zitting

Mime
View raw message