Hello,
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) :
http://issues.apache.org/jira/browse/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,
Christophe
Best regards,
Sandro
