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
