Hi all, As explained by Costin, it is quite difficult to synchronise both projects (Spring module & our JCR mapping tools) due to major changes in our tools. That's why I created a tempory subproject jcr/spring to have an intermadiate Spring support.
Personnally, I think the ASF JCR federation is the best place because the JCR mapping is not targeted only for Jackrabbit. We can add support for other JCR repo (Alfresco, Jeceira, ...). I can understand that it can take times to create the JCR federation. So, the current best place is certainly the Jackrabbit project. Jukka, can you start this process and discussion with other Jackrabbit commiters ? Last point, some comments on the JCR mapping status : * It is quite stable for basic mapping strategies including associations (1..1 , 1..n) * It is also supporting object inheritance and interfaces. * Object loading can be optimized with proxies or with the option "auto-retrieve". * It is possible to customize the mapping strategies with converters for atomic types, collections and bean attributes. * we are also supporting versionning and object locks. Unfortunatly, the documentation is not updated for advanced mapping strategies. Further improvements can be : 1/ Add a strong object caching support 2/ Support more mapping flexilbities (eg. : http://issues.apache.org/jira/browse/GRFT-54). 3/ Security - add a fine grained access control based on JAAS. 4/ Add advanced search option (see : http://issues.apache.org/jira/browse/GRFT-60). 5/ Support other JCR repo 6/ Use java annotation to specify the mapping definition. 7/ ... and many others. On 7/13/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi, On 7/13/06, Costin Leau <[EMAIL PROTECTED]> wrote: > # since both me and Spring Modules were mentioned, I though I should > # clarify things a bit Thanks for joining! > I think a mapping tool for JCR would be a very useful tool and I'd be > glad to support it inside Spring Modules (I'm not sure if it makes sense > to move it there). However, I think it's really premature to discuss > such issue before the tool is finalized. That's reasonable. I haven't yet looked deeper into the code, so I'm not too familiar with the maturity of the subproject. What's the current status in terms of the main use cases? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
-- Best regards, Christophe
