jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: Distribution of commons classes
Date Fri, 05 Oct 2007 13:55:43 GMT

Stefan Guggisberg wrote:
> On 7/26/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> 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.
 >> [...]
>> WDYT?
> +1, sounds good.
> cheers
> stefan
>> BR,
>> Jukka Zitting

i'd like to take up the discussion regarding distribution
of the jcr-commons-classes and the related issue JCR-996
and come up with an proposal.
it summarizes the findings of my initial efforts while working
on JCR-996 on the current jackrabbit trunk. i tested the general 
feasibility on the spi project and on parts of the jackrabbit-core.

please comment.


- modify without breaking existing dependencies to it.

- therefore rather deprecate than move classes related to
   internal functionality of a JCR impl.
   this mainly affects classes used for namespace handling and
   name/path conversion:

   > org.apache.jackrabbit.name.*.java
   > org.apache.jackrabbit.util.name.*.java

- in addition the following 'utility' classes:

   > org.apache.jackrabbit.util.PathMap
   > org.apache.jackrabbit.util.Locked
   > org.apache.jackrabbit.BaseException

- eventually deprecated methods that define param/return
   values to be any of the classes mentioned above

   > o.a.j.value.NameValue.valueOf(QName, NamespaceResolver)
   > o.a.j.util.ISO9075.encode(QName)
   > o.a.j.util.ISO9075.decode(QName)

- move the alternative ValueFactory implementation that
   does not require a reference value to be a UUID from
   jackrabbit-spi-commons to the o.a.j.value package.


- copy classes that have been deprecated in jcr-commons
   to different packages in the spi-commons.

   > namespace handling      -> o.a.j.namespace
   > name/path conversion    -> o.a.j.conversion
   > creation Name/Path      -> o.a.j.name
   > o.a.j.util.PathMap      -> o.a.j.name (?)
   > o.a.j.util.Locked       -> o.a.j.lock (?)

- replace usages of QName/Path within the conversion
   and utility classes with Name/Path interfaces

- provide default factories for both Name and Path based
   on the current QName and Path classes.

- get rid of duplicate conversion functionality provided
   both by *Resolver interfaces and by *Format classes.
   i would opt for using the *Resolver interfaces.

- add o.a.j.name.NameConstants for the various predefined
   and widely used names.

- since the proposed Name/Path interfaces do currently
   not make usage of the BaseException but rather use
   RepositoryException, i would in addition suggest to
   make the various internal exceptions extend RepositoryExc.

jackrabbit-spi (see JCR-996)

- define Name, Path and *Factory interfaces
- change all SPI interfaces to use Name/Path interfaces
- remove dependency to jackrabbit-jcr-commons

View raw message