Christophe Lombart wrote:Hi All,
I would like to start the JCR integration into Graffito. This is a summary on how I see this integration :
* 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.
What do you think about that ?
Do you have some ideas, comments for such JCR mapping framework ? Is it make sense for you ?For JCR integration, what do you think about Stephane's proposal of a "Lenya CMS Framework or Jackrabbit Framework"?
As mentionned I still think it would be great to try to open a a "cms-commons" community (as a side note, David, it would be great to have a "portal-commons" project too ;-) ) in order to federate what can be federated on top of the JCR RI rather than trying to reinvent the wheel and split the community.
I would think that the Graffito integration would be implemented with Jackrabbit, right?
I was thinking so (graffito being on top of Jackrabbit), but this description of Graffito looks more just like a JCR compliant API (which level?) on top of the current existing code base rather than a full refactoring.
BTW: Serge recently contributed an Hibernate + OJB persistance layer implementation for Jackrabbit... So here again is it really worth ajusting the current code base to get some JCR compatibility rather than refactoring the whole project on top of Jackrabbit (interfaces may then simplify content definition, templates development,...).
Just my 2 cts... St�phane
- -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- -
www.jahia.org : The Open Unified Web Platform
