jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: common libraries for jcr and jackrabbit (NodeType-Constants)
Date Fri, 08 Jul 2005 07:40:06 GMT
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

Tobias Strasser wrote:
> On 7/6/05, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
>>On 7/6/05, Tobias Strasser <tobias.strasser@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
>>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
>>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.

View raw message