I am trying to summarize my comments below... (to Alex Lukin):
> 1) Current ocm in jackrabbit source tree does not have anything in common > with JPA annotation and/or ideology Because it started on that direction. That doesn't mean it is the best approach. But falling back again to the Hibernate parallel: once JPA was introduced they were able to add support for JPA quite soon, considering they have had a stable ORM. I assume the same will happen here sooner or later. > 2) JPA is based on relational approach and does not work properly with > tree-like structures we use often with JCR That's partly correct. Indeed the theory of relational storage and tree-based storage are radically different. > 3) JPA is monstrous as current jackrabbit OCM is. I take this as your opinion, so I will not really comment on it. > I checked jcrom and created nodes in 5 minutes. Current OCM took much much > more time to go trough broken docs, complicated tests and hanging ends... > [...] > > > > So my opinion is: Simple and quick OCM like jcrom.org is just great > > solution. > > > > If some standard-addicted company wants to implement JPA on top JCR - > > that's good. > > If current "official" OCM is more flexible and powerfull - that's good too, > > but I need working OCM now and can't wait new implementations and > > neverending doc fixings. > You are mentioning the current status of 2 projects and your own needs. That's fine with me, and as I said: I do appreciate any efforts in making JCR adoption easier. However, my comments were more about the future of this technology and things that people looking into creating projects around JCR should be looking for. (to Ivan Latysh) > Just my 2 cents, Jack Rabbit will not provide any advantages for Java Object > Mapping, on the opposite side, will cause you many problems. As it mentioned > before JR works with tree structures and not collections. > I must confess that I don't get your comment. I don't think OCM or JCROM intention is to innovate in terms of Java Object to X mapping but rather to address the problem at hand. And they are not looking to provide a generic solution, but rather a working one in this field. (to Christophe) > There are commons points between both solutions in term of annotations but > JCROM doesn't support lazy loading, interface and ínheritance, custom > converter, .... Futhermore Jackrabbit OCM makes more abstraction on the JCR > API which is not the case of JCROM. These are indeed feature that everybody will start considering at the point their application gets complex enough. However, people may consider that annotation based metadata to be easier to create and maintain than XML, and so putting them together will make sense. I am not saying that in the current form, or in a more JPA-like form. (to David) >> Moreover, when speaking about mapping solutions I would be interesting >> in the level of customization they allow >> and keeping in mind some of the JCR storage restrictions how these are >> handled (the first example that comes into my mind is a parent-child >> relationship with 10k children). > I am not sure if you are referring to the performance penalties in the > current jackrabbit implementation with a large number of direct child > nodes. I want to be clear though that JCR does not have any limitation > or performance penalty with a large number of direct child nodes. You are right: I was referring to the current Jackrabbit limitation. Even if JCR does not have any such limitations (because it is a spec), by looking at the history of the tree-based storage I think we can say that this was almost always a real problem (and if we take as example the FS implementations we will notice that just the latest implementations have been finally able to solve this old historical problem). > I am convinced that the JCROM project would be happy to receive a patch ...after all it is an opensource project ;) Well, my current status (plus my financial statement) are telling me that I am not the right person for this. Moreover, I do think that is time to leave some room for the younger to get involved in the open source ;-). cheers to everybody, ./alex -- .w( the_mindstorm )p.
