Re: Distribution of commons classes

[Angela Schreiber <an...@day.com>]

hi

Stefan Guggisberg wrote:
> On 7/26/07, Jukka Zitting <ju...@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.
regards
angela


----------------------------------------------------------
jackrabbit-jcr-commons
----------------------------------------------------------

- 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.


----------------------------------------------------------
jackrabbit-spi-commons
----------------------------------------------------------

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

   > 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

Re: Distribution of commons classes

[Julian Reschke <ju...@gmx.de>]

Angela Schreiber wrote:
> ....
> 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.
> ...

Caveat: I only have limited insight into jackrabbit-core.

But from the perspective of reducing code duplication between the 
monolithic jackrabbit and the JCR2SPI this makes a lot of sense to me.

+1.

Best regards, Julian