incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <>
Subject Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Date Sun, 10 Jul 2005 08:07:21 GMT
Hi Sandro, 

I going to review all (probably this week).
If I understand, everythin is in JIRA - correct ? Personnally, I think
you can commit your code directly into CVS (with branch creation).


2005/7/9, Sandro Boehme (JIRA) <>:
>      [ ]
> Sandro Boehme updated GRFT-34:
> ------------------------------
>     Attachment:
> Hello,
> attached you find an initial code base for the mapping project. I would like to reach
> general consensus about some issues to be able to adopt some things before I
> initially commit it. Please feel free to create new threads in the mailing list for
> different issues raised in this email.
> Regarding general quality and quality of documentation:
> Instead of improving the documentation until it's perfect, understandable by everyone
> and writing sentences that are grammatically and orthographically (not sure if it's
> written the right way ;-) ) perfect I decided to share it with you as it is. Not only
> regarding the documentation: I don't like to send work where I could not finished think
> about it, especially in such a public area. But it would take to much time to synchronize
> with you instead. At the other hand, the documentation should be good enough for being
> replacable when I should decide to go on a journey round the world for the next year
> Probably the best way to explore how things are working exactly is to debug through the
> NodeTypeRegistration and the PersistanceManagerTest.
> Current mapping semantics:
> JCR nodetype <==> Java class
> JCR child node <==> Java method
> JCR value <==> The class of the returning object of a Java method. The registered
> types should care about the conversion of classes and values.
> Required primary types:
> A Childnode Definition does not have only one type like a return type of a Java method.
> Instead it has a list of required primary types.
> I interpret it like this:
> If you have a Java method signiture that returns "java.lang.Object", then the
> RequiredPrimaryTypes is the list of Java classes / node types that are allowed to be
> returned _at_runtime_.
> I don't have an idea at the moment how to ensure the integrety for this at runtime without
> introducing performance problems.
> The attached zip file contains the following components:
> The mapping model
> A node type registration component for Jackrabbit
> Components for the persistence:
>         o atomic type converter
>         o object to item converter
> Changing of nodetypes which are used by nodes:
> As we map Java semantics to node type semantics, it would be nice for the continuous
> integration that we can reregister nodetypes when Java classes are changing.
> But at the moment changing of nodetypes which are used by nodes is not yet implemented.
> I guess it is very hard to implement. But I will ask for an opinion on this at the
> Jackrabbit mailing list.
> At the moment I delete the complete repository in order to test the node type registration.
> Some unsorted notes/questions:
> o We need to add exception handling to the code base.
> o We need to support for Collections and Interfaces.
> o Maybe it makes sense to improve the design of the object
>   to item converter and the jackrabbit node type registration
>   by seperating the adapter classes from the recusive traversal.
> o Is checkstyle applied to the code when I commit files so
>   I don't need to deal with the Apache code formatting and
>   the Apache license in my IDE (btw: it's Eclipse)?
>   Especially for the classes generated by JAXB it would be
>   good to know, that I don't need to add the licence with
>   a regular expression.
> Source code decoration:
>   The mapping model is specified with an XML file. The definition of one mapping can
>   be quite big, when you need to type all informations in the file by yourself. It
>   would also be very error prone for typos.
>   At the moment it would at least be really helpful for creating testcases to have
>   some sort of source code decoration with annotations or with XDoclet. As the Java
>   source code already contains the Java part of the mapping definition, you would only
>   need to decorate the classes or methods with node type information and we have a
>   complete mapping definition for creating the according mapping XML-file.
>   Later I could imagine to also support MDD to create the mapping XML-file out of a model
>   of a higher level.
> Some quick ideas about use cases:
> In my opinion, if I don't ignore something, the mapping project can also be useful
> for CMS's that don't want to change very much of their domain model and instead
> want to use our mapping to adopt their classes to nodetypes.
> I guess the Jackrabbit WebDav server uses specific node types (I did not check it).
> So I think it should also be possible to use these node types and adopt them
> to an application domain model. This should make it easy to use the WebDav
> protocoll with an undependent application domain model.
> Things to discuss:
> Hi Oliver, the dynamic repository creation and the update of the Jackrabbit
> version was really helpful for implementing the basic version. This was not yet
> the thing to discuss ;-).
> Please feel free to tell me how I can adopt my registration component to fit to
> your ideas of the CustomNodeTypeCreator.
> The JCRSession seems to aim the same goal of the persistence manager. The reason
> why I called it "Persistence Manager" was simply to make it clear that the
> functionality of the class is, to persist objects (insert to repository,
> get from repository, search in repository,...). But I'm open to rename it.
> In the attached initial codebase you can specify the namespaces of the
> application domain model in the mapping model's xml file. Different node types
> can have different namespaces there. This is why I register the namespaces within
> the node type registration component. Your JCRSession also contains namespace
> registration, this is why I want to ask you, if my handling is ok from your point
> of view.
> Atomic types vs. custom node type converter:
> Hello Christophe, initially you had the idea of custom node type converter. I think the
> basic idea was to give users the freedom of having their own conversion.
> I think the atomic type converters in the current codebase what you wanted to archive
> with the custom node type converter. Please tell me if you had other things in mind.
> The atomic types should also be able to handle a little bit more complex Java types.
> Testcases:
> We can use adopted TCK testcases to test if we pass through all functionalities
> of the JCR. This would save us much time in comparison to test all JCR
> functionalities from the scratch.
> Projectname:
> As Christophe already mentioned, it would be nice to have a cool project name.
> Personally I don't have an idea, maybe an animal that has something to do
> with any kind of "mapping" ;-) ?
> In case you need it, the JAXB command I call in a script file is:
> xjc -classpath
> C:\SoftwareDevelopment\eclipseworkspace\jcr-mapping\target\classes
> -p org.apache.portals.graffito.jcr.testmodel
> -d C:\SoftwareDevelopment\eclipseworkspace\jcr-mapping\src\java
> -p org.apache.portals.graffito.jcr.mappingmodel.nodetypeschema custom_nodetypesV2.xsd
> Finally, what do you think about all that?
> Best regards,
> Sandro
> > An initial code base for the mapping project.
> > ---------------------------------------------
> >
> >          Key: GRFT-34
> >          URL:
> >      Project: Graffito
> >         Type: New Feature
> >     Reporter: Sandro Boehme
> >     Assignee: Sandro Boehme
> >  Attachments:,
> >
> > As the list does not allow attachments I upload the zip file to this issue.
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> -
> For more information on JIRA, see:

View raw message