Hi, First off, I am all for a promotion to the main stream.
But then, I am somewhat reserved with respect to the Node Type Management stuff. This is - as the respective API is not defined in JCR - depending on the Jackrabbit-Core library. So as first step, I suggest investigating whether it is possible and worth it to extract an API for node type management out of the core into jackrabbit-api. If we come to a positive conclusion, I am all for including the node type management stuff and write it against the new API. Otherwise, I wouls suggest to only include the mapping part and leave the node type management part out for the moment. As for the Spring stuff, I would not add/promote it. Rather I would think about moving this to the Spring Jackrabbit tools on dev.java.net. Finally, the mapping component should be made "implementation clean". That is, the mapping library has some references to jackrabbit-core which are mainly used for testing and should actually removed from the library as they have nothing todo AFAIK with the mapping itself. The reason why I insist on strictly removing any jackrabbit-core dependencies is, that in a distributed use case (e.g. RMI) or even in a standard installation where the repository runs in a separate web app and the jackrabbit-core library is not in a shared class path (which is correct), the jackrabbit-core classes are not available to the mapping code running in the application space web app. Regards Felix Am Dienstag, den 03.07.2007, 12:12 +0300 schrieb Jukka Zitting: > Hi, > > As has recently been discussed, I'd like to promote the OCM component > from contrib status to be released as a part of Jackrabbit 1.4. The > component is seeing increasing levels of use, and making a formal > release would make it easier for people to depend on the component in > external projects. Of course doing a release also means taking on the > responsibility of maintaining backwards compatibility. Do we have a > consensus that the component is ready for a release? > > I personally have just a single concern; we should decide what to do > with the current separation into jcr-mapping, jcr-nodemanagement, and > spring components. I would preferably see just a single > jackrabbit-jcr-ocm component being released, so we need to decide what > to include in that component and what to leave in contrib. AIUI it > might make sense to merge jcr-mapping and jcr-nodemanagement into this > single ocm component. > > BR, > > Jukka Zitting
