On 7/6/05, Stefan Guggisberg <[EMAIL PROTECTED]> wrote: > On 7/6/05, Tobias Strasser <[EMAIL PROTECTED]> 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.
