Re: common libraries for jcr and jackrabbit (NodeType-Constants)

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

hi

i ask yukka and stefan yesterday, whether it would be
possible to move the org\apache\jackrabbit\nodetype\xml\Constants.java
to the commons project as well.

background:
the jcr-server contribution defines a REPORT that
allows to retrieve nodetype definitions. i deliberately
built the xml in order to be identical to the xml-representation
defined in the jackrabbit core and used the jackrabbit
constants (not copying them over) in order to show that
dependency.

while removing any dependency for the core, i temporarily
copied that interface to the commons defined in the
jcr-server (again a temporarly solution from my point
of view).

since the new commons with the main-jackrabbit source
now causes problems, i would like to have that
interface defining some constants being available
in the jackrabbit-commons, so i could remove the
commons in jcr-server.

see private communication below.
thanks & regards

angela


-------- Original Message --------
Subject: [Fwd: Re: common libraries for jcr and jackrabbit] >> 
NodeType-Constants
Date: Wed, 06 Jul 2005

hi jukka

i just talked to stefan about the possibility to
move the org\apache\jackrabbit\nodetype\xml\Constants.java
to the commons-library, that has been created this week.

i'm using those constants for generating a nodetype
REPORT in my jcr-server and copied the class over
to the commons-module in the jcr-server (you may
remember the discussion about having the contributions
being independant of the jackrabbit core).

with the introduction of the jackrabbit commons/api
it would be cool, if i could get rid if those 'commons'
in the jcr-server being a temporary solution only which
duplicate code....

stefan thought it would be better, if you would
decide on this :)

my opinion: i would be very happy, if the Constants
would be moved over to the commons... even if that
is only a small step towards a nodetype-package
that is less tightly coupled to the jackrabbit core.

thanks & kind regards to the very north!
angela



-------- Original Message --------
Subject: Re: [Fwd: Re: common libraries for jcr and jackrabbit] >> 
NodeType-Constants
Date: Wed, 06 Jul 2005

Hi Angela & Stefan,

Angela wrote:
> i just talked to stefan about the possibility to
> move the org\apache\jackrabbit\nodetype\xml\Constants.java
> to the commons-library, that has been created this week.
> [...]
> stefan thought it would be better, if you would
> decide on this :)

OK, thanks. :-)

First, I think that the basic idea is good, the jackrabbit-commons
library is a great way to avoid duplicating code. However, the nodetype
XML format is currently mostly Jackrabbit-specific, and thus would more
likely belong to jackrabbit-core than jackrabbit-commons. But, as you
are already using it on webdav and there is no other common XML
representation for nodetypes, we could simply define the Jackrabbit
nodetype format as the de-facto standard and move the related code into
jackrabbit-commons for others to use as well.

So yes, I think this would be a good step, and I'd be happy to assist in
the more general goal of moving the o.a.j.c.nodetype.xml (and parts of
nodetype!) code from -core to -commons (some refactoring would probably
be needed to remove the core dependencies). Before we do this however,
it would be good to at least notify jackrabbit-dev about this to
maintain transparency and keep the community up to date. :-)

BR,

Jukka Zitting

Re: common libraries for jcr and jackrabbit (NodeType-Constants)

[Stefan Guggisberg <st...@gmail.com>]

On 7/6/05, Jukka Zitting <jz...@yukatan.fi> wrote:
> Hi,
> 
> Angela Schreiber wrote:
> > since the new commons with the main-jackrabbit source
> > now causes problems, i would like to have that
> > interface defining some constants being available
> > in the jackrabbit-commons, so i could remove the
> > commons in jcr-server.
> 
> +1, as explained in the message forwarded by Angela.
> 
> Additionally, I'd like to refactor the internal Jackrabbit nodetype
> object model and the nodetype XML format code into jackrabbit-commons.
> I've already done this work for the contrib/jcr-ext package to be used
> for my JCR adapter projects, but having a shared codebase with
> Jackrabbit would be _so_ much better.

+1

cheers
stefan

>
> Any objections or comments about me doing this?
> 
> BR,
> 
> Jukka Zitting
>

Re: common libraries for jcr and jackrabbit (NodeType-Constants)

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

i'm fine with either way. however it sounds to me,
that it will take some time :)

would it be an option to move the nodetype-xml-constants
for the time being as requested in my original mail?

- if the serialization format remains the same the
   constants can happily stay in the commons forever

- if the serialization format is adapted, refactored,
   modified, i will have to change that particular
   part of the jcr-server anyway... but i would prefer
   if the code would not compile then instead of
   producing useless xml output...
   bref: as i stated before, making the dependency obvious.

merci & gruss
angela

Tobias Strasser wrote:
> On 7/6/05, Stefan Guggisberg <st...@gmail.com> wrote:
> 
>>On 7/6/05, Tobias Strasser <to...@gmail.com> wrote:
>>
>>>>Angela Schreiber wrote:
>>>>
>>>>>since the new commons with the main-jackrabbit source
>>>>>now causes problems, i would like to have that
>>>>>interface defining some constants being available
>>>>>in the jackrabbit-commons, so i could remove the
>>>>>commons in jcr-server.
>>>>
>>>>+1, as explained in the message forwarded by Angela.
>>>>
>>>>Additionally, I'd like to refactor the internal Jackrabbit nodetype
>>>>object model and the nodetype XML format code into jackrabbit-commons.
>>>>I've already done this work for the contrib/jcr-ext package to be used
>>>>for my JCR adapter projects, but having a shared codebase with
>>>>Jackrabbit would be _so_ much better.
>>>
>>>that would be cool.
>>>
>>>additionally, i thought of a more jcr-like way for an xml format of
>>>the nodetypes. why not using the docview serialization of the
>>>respective nt:nodeType nodes that represent the nodetype? the
>>>advantage would be, that the format and structure are already
>>>indirectly defined within jcr, export and import are also available in
>>>jackrabbit.
>>
>>using docview serialization sounds like a good idea. however docview is
>>not guaranteed to safely roundtrip. e.g. there's the problem with multi-valued
>>properties. according to the spec it's up to the implementation how it
>>should handle those on export/import.
> 
> this might be a problem since for example jcr:defaultValues is a mv property
> 
> 
>>also, i'd rather not stretch the already very complicated semantics of
>>Session/Workspace.importXML with new features like 'auto-register node
>>types'.
>>node type management should IMO be the sole responsability of a
>>dedicated NodeTypeRegistry.
> 
> sure, in a first step i just thought of adapting the serialization format.

Re: common libraries for jcr and jackrabbit (NodeType-Constants)

[Tobias Strasser <to...@gmail.com>]

On 7/6/05, Stefan Guggisberg <st...@gmail.com> wrote:
> On 7/6/05, Tobias Strasser <to...@gmail.com> wrote:
> > > Angela Schreiber wrote:
> > > > since the new commons with the main-jackrabbit source
> > > > now causes problems, i would like to have that
> > > > interface defining some constants being available
> > > > in the jackrabbit-commons, so i could remove the
> > > > commons in jcr-server.
> > >
> > > +1, as explained in the message forwarded by Angela.
> > >
> > > Additionally, I'd like to refactor the internal Jackrabbit nodetype
> > > object model and the nodetype XML format code into jackrabbit-commons.
> > > I've already done this work for the contrib/jcr-ext package to be used
> > > for my JCR adapter projects, but having a shared codebase with
> > > Jackrabbit would be _so_ much better.
> >
> > that would be cool.
> >
> > additionally, i thought of a more jcr-like way for an xml format of
> > the nodetypes. why not using the docview serialization of the
> > respective nt:nodeType nodes that represent the nodetype? the
> > advantage would be, that the format and structure are already
> > indirectly defined within jcr, export and import are also available in
> > jackrabbit.
> 
> using docview serialization sounds like a good idea. however docview is
> not guaranteed to safely roundtrip. e.g. there's the problem with multi-valued
> properties. according to the spec it's up to the implementation how it
> should handle those on export/import.
this might be a problem since for example jcr:defaultValues is a mv property

> also, i'd rather not stretch the already very complicated semantics of
> Session/Workspace.importXML with new features like 'auto-register node
> types'.
> node type management should IMO be the sole responsability of a
> dedicated NodeTypeRegistry.
sure, in a first step i just thought of adapting the serialization format.

Re: common libraries for jcr and jackrabbit (NodeType-Constants)

[Stefan Guggisberg <st...@gmail.com>]

On 7/6/05, Tobias Strasser <to...@gmail.com> wrote:
> > Angela Schreiber wrote:
> > > since the new commons with the main-jackrabbit source
> > > now causes problems, i would like to have that
> > > interface defining some constants being available
> > > in the jackrabbit-commons, so i could remove the
> > > commons in jcr-server.
> >
> > +1, as explained in the message forwarded by Angela.
> >
> > Additionally, I'd like to refactor the internal Jackrabbit nodetype
> > object model and the nodetype XML format code into jackrabbit-commons.
> > I've already done this work for the contrib/jcr-ext package to be used
> > for my JCR adapter projects, but having a shared codebase with
> > Jackrabbit would be _so_ much better.
> 
> that would be cool.
> 
> additionally, i thought of a more jcr-like way for an xml format of
> the nodetypes. why not using the docview serialization of the
> respective nt:nodeType nodes that represent the nodetype? the
> advantage would be, that the format and structure are already
> indirectly defined within jcr, export and import are also available in
> jackrabbit.

using docview serialization sounds like a good idea. however docview is 
not guaranteed to safely roundtrip. e.g. there's the problem with multi-valued 
properties. according to the spec it's up to the implementation how it 
should handle those on export/import. 

also, i'd rather not stretch the already very complicated semantics of
Session/Workspace.importXML with new features like 'auto-register node
types'.
node type management should IMO be the sole responsability of a
dedicated NodeTypeRegistry.

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 (NodeType-Constants)

[Tobias Strasser <to...@gmail.com>]

> Angela Schreiber wrote:
> > since the new commons with the main-jackrabbit source
> > now causes problems, i would like to have that
> > interface defining some constants being available
> > in the jackrabbit-commons, so i could remove the
> > commons in jcr-server.
> 
> +1, as explained in the message forwarded by Angela.
> 
> Additionally, I'd like to refactor the internal Jackrabbit nodetype
> object model and the nodetype XML format code into jackrabbit-commons.
> I've already done this work for the contrib/jcr-ext package to be used
> for my JCR adapter projects, but having a shared codebase with
> Jackrabbit would be _so_ much better.

that would be cool.

additionally, i thought of a more jcr-like way for an xml format of
the nodetypes. why not using the docview serialization of the
respective nt:nodeType nodes that represent the nodetype? the
advantage would be, that the format and structure are already
indirectly defined within jcr, export and import are also available in
jackrabbit.

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 (NodeType-Constants)

[Jukka Zitting <jz...@yukatan.fi>]

Hi,

Angela Schreiber wrote:
> since the new commons with the main-jackrabbit source
> now causes problems, i would like to have that
> interface defining some constants being available
> in the jackrabbit-commons, so i could remove the
> commons in jcr-server.

+1, as explained in the message forwarded by Angela.

Additionally, I'd like to refactor the internal Jackrabbit nodetype 
object model and the nodetype XML format code into jackrabbit-commons. 
I've already done this work for the contrib/jcr-ext package to be used 
for my JCR adapter projects, but having a shared codebase with 
Jackrabbit would be _so_ much better.

Any objections or comments about me doing this?

BR,

Jukka Zitting