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