incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <>
Subject Re: JCR-Mapping VOTE : All commiters has to vote - Thanks
Date Sat, 06 Aug 2005 13:42:55 GMT

>Hi all, 
>I would like to ask you to vote for the following proposal. Some of us
>are not agree on how to implemented it. So, it should be nice to have
>the vote from everyone.
>We should wait until all commiters make their vote. Please don't vote
>"+0". We are already waste a lot of time.
I don't think the time is wasted. We can only develop together in the 
same direction if we have
a consensus about the basics. If you think we should be ready to jump 
earlier on the JCR
bandwagon I could live with DTD and Digester if we later really try to 
come to a consensus.

>JCR-Mapping  - The situation 
>This subproject was created to support JCR into Graffito. The main
>idea is to build a Jcr-Object mapping supporting the following
>features :
>o writing Java objects as nodes to the repository
>o loading nodes from the repository into Java objects
>o generating node types out of Java classes
>o generating Java classes out of node types
>o search information and return result as object graph,  ...
>So, it looks like OJB, Hibernate, ... but obviously for a JCR repository. 
>The problem
>Like those tools (OJB, ...) ,  our framework needs a xml mapping file
>containing for each java bean class the mapping strategy. We are not
>agree on how to manage this file (tools & technology).
>Proposal 1 (Christophe)
>* I'm doing a prototype - see in the head (subproject jcr-mapping).
>The starting point is the unit test called : JcrSessionTest
>This code do the following steps : 
>* Read the mapping file with Digester and load it in memory (object
>graph) - See the class DescriptorReader in the prototype. The
>prototype is not complete.
>* A simple DTD is sufficiant for this kind of operation. 
>* Use BeanUtil to convert in both direction pojo <-> jcr node (see in
>the prototype the class : GenericConverter).
>+ : simple code and light tools
>- : classes used to read the mapping file have to be write by hand.
>Thanks to the limited number of classes, it should not be a problem.
>Proposal 2 (Sandro) 
>* Sandro made a prototype - see in Jira ( GRFT-34) :
>* Use XmlSchema and tools like JAXB or XmlSchema to manage the xml mapping file.
Arguments for XML schema and XMLBeans:
+ : The XML schema and the mapping class model are redundant information 
in my opinion. So for me
it seems to be straightforward to generate the mapping model classes out 
of the XML
schema (e.g. with XMLBeans). You will need to change the mapping class 
model if the
specification of the XML file changes and vice versa.

+ : Isn't it also possible for Digester to use XML Schema? I think so, 
but I guess I'm not the
Digester expert here.
+ : The XML schema and the classes should not get out of sync.
+ : With the type support of XML schema I think we could reproduce many 
of the JCR
entities from items down to concrete JCR property types and of course 
Java bean
structures. This makes it possible to have very much semantics of the 
XML file already
validated by the XML schema.
- : A Class and an Interface is generated for each type.
- : As XML Beans is a generator is should be sufficient to have the 
license in the xsd file.
But to be sure I would like to have it in the generated classes. This 
would need some
extra effort. Of course I'm in charge to care about it.
- : Extensions to the generated classes should not be needed very often. 
In case it is
needed, the classes are extended in a not quite familiar way.

>Why I'm not agree with Sandro : 
>I don't see the advantage to use the XML schema in THIS case. The xml
>mapping file has to be quite simple to read and generate classes is
>overkill in this situation. We can do exactly the same think with very
>light tools... but maybe I'm wrong !
>Please make your vote : 
>1. Proposal 1 : mainly Digester & BeanUtil
>2. Proposal 2  : XmlSchema & tools like XmlBean
>3. Create a branch and make 2 prototypes to compare them. there are
>too many understanding between us. So, it should be nice to write a
>user requirement to clarrify everything. At least the mapping file
>structure and the high level API.
>Here is my vote because I'm going in vacation for 2 weeks :-))))
Hey, if you are near to Stuttgart (Germany) and if you want, we can go 
have a beer. Of course
only if you drink a beer with XMLBean dudes ;-).

>+1 for 3. Create a branch and make 2 prototypes to compare them before
>taking a decision (+small user requirements).
+1 for 3. I'm not sure if it is needed to check my prototype in.
But for me it's more about finding good arguments and consensus.
That would lead to a situation where everybody is willing to support the 
way to go instead of
having one who is overruled and don't really understands why.

I afraid, if I ever have kids I will wish that I've never written that. :-)

>Kind regards, 
Best regards,


View raw message