> * I want to leave our persistence service as it is. I don't want to > replace it by a new JCR implementation. I don't want to change the > Graffito API which is *very* simple to use. I see only some minor > changes in the version & search services. > * JCR integration can be made with a new implementation for the > org.apache.portals.graffito.store.ContentStore and a new Server class > (eg. org.apache.portals.graffito.model.JCRServer). > * I would like to create a new subproject which will contains a JCR > mapping framework. The goal of this framework is to store any java beans > (CmsObject) in a JCR repository.This framework will be used by the JCR > ContentStore implementation and if needed, can be used outside the > Graffito engine. After a lot of discussion on that topic, I would like > to start with a very simple solution based on a converter class for > each CmsObject types (Document, Folder, ...). So if a new CmsObject > class is required for a custom application, the developer has to write a > new JCR converter class. Later, we can write more advanced/generic > converter implementations based on introspection or similar techniques.
I would like to volunteer to implement a jcr persistence layer for graffito based on jackrabbit as described by christophe (simple solution based on a converter class). I have some experience with jackrabbit und decent knowledge of the jcr spec. I have spent some time developing a jcr object persistence framework myself (not a mapping framework) and have looked into the graffito sourcecode to make sure jcr can be integrated which I think is possible with little or no changes to the existing graffito API. Concerning the advanced jcr mapping framework I think my existing jcr framework code is a little different conceptually and I don't want to get into this for now. Please let me know if this makes sense to you, if so I'd be pleased to join in. regards, oliver
