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).
Thanks, Christophe 2005/7/9, Sandro Boehme (JIRA) <[EMAIL PROTECTED]>: > [ http://issues.apache.org/jira/browse/GRFT-34?page=all ] > > Sandro Boehme updated GRFT-34: > ------------------------------ > > Attachment: src_folder.zip > > 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 atomic > 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" ;-) ? > > JAXB: > 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: http://issues.apache.org/jira/browse/GRFT-34 > > Project: Graffito > > Type: New Feature > > Reporter: Sandro Boehme > > Assignee: Sandro Boehme > > Attachments: jaxb_libs.zip, src_folder.zip > > > > 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: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira > >
