You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Tobias Strasser <to...@gmail.com> on 2005/05/19 10:58:39 UTC
common libraries for jcr and jackrabbit
hi,
as discussed in other threads, there is a need for commons or helper
libraries, containing either JCR related or Jackrabbit related stuff.
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.
or we should start thinking of a jackrabbit-api. that would contain
also those classes.
however:
- what is the general feeling about this?
- what would be the names of those libs; is commons-jcr allowed, or is
this reserved to jakarta projects?
- is it ok for jackrabbit core to depend on commons-jackrabbit and commons-jcr ?
- how should the maven projects look like?
cheers, tobi
--
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: common libraries for jcr and jackrabbit
Posted by Jukka Zitting <jz...@yukatan.fi>.
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
Re: common libraries for jcr and jackrabbit
Posted by Stefan Guggisberg <st...@gmail.com>.
On 7/1/05, Tobias Strasser <to...@gmail.com> wrote:
> hi,
> to revitalize this old topic, i made some structural changes to the
> jackrabbit project,
> divding it into:
>
> jackrabbit
> +- api
> +- commons
> +- core
>
> the core contains the former 'src/java' stuff from jackrabbit
> the commons will contain commonly used classes (currently only Text.java)
> the api will contain interfaces for accessing jackrabbit (currently empty)
>
> the top maven project builds the other three ones. and the tests are still
> performed in 'core' (guess this is easier).
>
> should i commit the changes, so we can make further adaptions until
> everything works again as expected?
+1
cheers
stefan
>
> cheers, tobi
>
> --
> ------------------------------------------< tobias.strasser@day.com >---
> Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
Re: common libraries for jcr and jackrabbit
Posted by Stefan Guggisberg <st...@gmail.com>.
On 7/1/05, Marcel Reutegger <ma...@gmx.net> wrote:
> Hi Tobi,
>
> Tobias Strasser wrote:
> > hi,
> > to revitalize this old topic, i made some structural changes to the
> > jackrabbit project,
> > divding it into:
> >
> > jackrabbit
> > +- api
> > +- commons
> > +- core
> >
> > the core contains the former 'src/java' stuff from jackrabbit
> > the commons will contain commonly used classes (currently only Text.java)
> > the api will contain interfaces for accessing jackrabbit (currently empty)
>
> what's your vision for interfaces in api? apparently it does not contain
> the interfaces we already specified e.g. for the persistence managers
> and filesystem implementations. or will we move them into the api module
> sometime?
i guess the idea is to add interfaces for those features that are available
in jackrabbit but are not (yet?) covered by the jsr 170 spec, e.g. workspace
mgmt., node type mgmt. etc.
cheers
stefan
>
> regards
> marcel
>
Re: common libraries for jcr and jackrabbit
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Tobi,
Tobias Strasser wrote:
> hi,
> to revitalize this old topic, i made some structural changes to the
> jackrabbit project,
> divding it into:
>
> jackrabbit
> +- api
> +- commons
> +- core
>
> the core contains the former 'src/java' stuff from jackrabbit
> the commons will contain commonly used classes (currently only Text.java)
> the api will contain interfaces for accessing jackrabbit (currently empty)
what's your vision for interfaces in api? apparently it does not contain
the interfaces we already specified e.g. for the persistence managers
and filesystem implementations. or will we move them into the api module
sometime?
regards
marcel
Re: common libraries for jcr and jackrabbit
Posted by Stefan Guggisberg <st...@gmail.com>.
On 7/1/05, Jukka Zitting <ju...@zitting.name> wrote:
> Hi,
>
> Tobias Strasser wrote:
> > the core contains the former 'src/java' stuff from jackrabbit
> > the commons will contain commonly used classes (currently only Text.java)
> > the api will contain interfaces for accessing jackrabbit (currently empty)
>
> Sounds excellent. My initial wishlist for things to refactor into the
> commons library:
>
> * Value classes (at least the simple ones)
done
> * QName and Path classes
done
i also moved the following from core to commons:
- util.uuid.*
- ISO8601 and some other generic helper classes
- NamespaceResolver and related exceptions
- Constants (e.g. wellknown proeprty names etc)
cheers
stefan
> * Some general-purpose base classes (like the ones in JCR-EXT)
> * XML import and export features
> * Query features (at least the language parsers)
>
> > should i commit the changes, so we can make further adaptions until
> > everything works again as expected?
>
> +1 I'd be happy to help out in implementing this.
>
> BR,
>
> Jukka Zitting
>
Re: common libraries for jcr and jackrabbit
Posted by Stefan Guggisberg <st...@gmail.com>.
On 7/1/05, Jukka Zitting <ju...@zitting.name> wrote:
> Hi,
>
> Tobias Strasser wrote:
> > the core contains the former 'src/java' stuff from jackrabbit
> > the commons will contain commonly used classes (currently only Text.java)
> > the api will contain interfaces for accessing jackrabbit (currently empty)
>
> Sounds excellent. My initial wishlist for things to refactor into the
> commons library:
>
> * Value classes (at least the simple ones)
> * QName and Path classes
that's what i also had in mind. other candidates are UUID, ISO8601, etc.
as soon as tobi did the project restructuring i'll move those from the core to
the commons subproject.
cheers
stefan
> * Some general-purpose base classes (like the ones in JCR-EXT)
> * XML import and export features
> * Query features (at least the language parsers)
>
> > should i commit the changes, so we can make further adaptions until
> > everything works again as expected?
>
> +1 I'd be happy to help out in implementing this.
>
> BR,
>
> Jukka Zitting
>
Re: common libraries for jcr and jackrabbit
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Tobias Strasser wrote:
> the core contains the former 'src/java' stuff from jackrabbit
> the commons will contain commonly used classes (currently only Text.java)
> the api will contain interfaces for accessing jackrabbit (currently empty)
Sounds excellent. My initial wishlist for things to refactor into the
commons library:
* Value classes (at least the simple ones)
* QName and Path classes
* Some general-purpose base classes (like the ones in JCR-EXT)
* XML import and export features
* Query features (at least the language parsers)
> should i commit the changes, so we can make further adaptions until
> everything works again as expected?
+1 I'd be happy to help out in implementing this.
BR,
Jukka Zitting
Re: common libraries for jcr and jackrabbit
Posted by Tobias Strasser <to...@gmail.com>.
hi,
to revitalize this old topic, i made some structural changes to the
jackrabbit project,
divding it into:
jackrabbit
+- api
+- commons
+- core
the core contains the former 'src/java' stuff from jackrabbit
the commons will contain commonly used classes (currently only Text.java)
the api will contain interfaces for accessing jackrabbit (currently empty)
the top maven project builds the other three ones. and the tests are still
performed in 'core' (guess this is easier).
should i commit the changes, so we can make further adaptions until
everything works again as expected?
cheers, tobi
--
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: common libraries for jcr and jackrabbit
Posted by David Nuescheler <da...@gmail.com>.
> >or we should start thinking of a jackrabbit-api. that would contain
> >also those classes.
> >
> >however:
> >- what is the general feeling about this?
> >
> >
> I see no reason for a Jackrabbit API except perhaps regarding the
> NodeType Management stuff, which would be nice if it would be available
> in a way that for example the RMI layer could also provide those without
> relying on core Jackrabbit.
i think a public jackrabbit API beyond jsr-170 would be a very healthy and
good thing, see http://incubator.apache.org/jackrabbit/arch/overview.html
i think this goes beyond nodetype management, it is really all the
functions that have been removed from the jcr api but we have a general
consensus that it a repository has to implement them in one form or
another.
this includes obviously things like nodetype mgmt, workspace mgmt,
access control but possibly also things like synchronous observation,
or parameters on stored queries.
those could all be candidates for inclusion in future versions
of the general jcr api.
generally, i think we should express somehow which jackrabbit
specific features a "jackrabbit application developer" should use.
currently this is not clearly visible in the jackrabbit java doc, since
there are a variety of reasons to make something "public".
regards,
david
Re: common libraries for jcr and jackrabbit
Posted by Felix Meschberger <Fe...@day.com>.
Hi,
Tobias Strasser schrieb:
>hi,
>as discussed in other threads, there is a need for commons or helper
>libraries, containing either JCR related or Jackrabbit related stuff.
>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.
>
>
I would think so. I would greatly appreciate if some more classes would
be provided there. For example the ISO8601 class, which additionally
might implement the Format interface or even DateFormat abstract class.
>or we should start thinking of a jackrabbit-api. that would contain
>also those classes.
>
>however:
>- what is the general feeling about this?
>
>
I see no reason for a Jackrabbit API except perhaps regarding the
NodeType Management stuff, which would be nice if it would be available
in a way that for example the RMI layer could also provide those without
relying on core Jackrabbit.
I providing common API, great care should be taken to create separate
libraries for UI (e.g. Servlets) and non-UI (e.g. Path, QName) stuff.
>- what would be the names of those libs; is commons-jcr allowed, or is
>this reserved to jakarta projects?
>- is it ok for jackrabbit core to depend on commons-jackrabbit and commons-jcr ?
>
>
I would definitely say so, otherwise the hole point of reusing common
classes would be void.
Regards
Felix