incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject JCR-Mapping VOTE : All commiters has to vote - Thanks
Date Thu, 04 Aug 2005 23:38:14 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.

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.

[Sandro, please add more details if needed]



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 :-))))

+1 for 3. Create a branch and make 2 prototypes to compare them before
taking a decision (+small user requirements).


Kind regards, 
Christophe

Mime
View raw message