hi
Stefan Guggisberg wrote:
On 7/26/07, Jukka Zitting <[EMAIL PROTECTED]> 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
