On 13/07/2010, at 3:57 AM, Ean Schuessler wrote: > Adrian Crum wrote: >>> we need is a factory for javax.jcr.Repository, and that >>> could be put in the content component. >>> >>> I would really prefer to not mix components for a couple of >>> reasons: >>> - Some of the existing content stuff should have been in >>> the framework IMO >>> - Mixing old and new in a single component is going to get >>> messy >>> >>> I would really rather see the repository and its associated >>> low level tools become part of the framework. I don't >>> care what we call it, jackrabbit was just the easy choice at >>> the time. >>> > I'm trying to understand what we want out of a Jackrabbit integration. > The API for accessing OFBiz content is definitely not a comfortable one > but I wonder if that isn't more of a reflection of its entities being > overly complicated. The DataResource/Content separation has its uses but > definitely makes creating content systems less than intuitive.
My goal is to fully replace the OFBiz content "repository" with one based on the JSR-283 spec. The branch is really only a means to experiment with that notion (for me), it could make its way into the trunk eventually or it could be thrown away, it really depends on how involved the community wants to be in the work and how useful the end product is compared to what we currently have. Why do it at all? Because the existing content model in OFBiz is IMO dead and we don't have the manpower to make it into what it should be and it isn't even clear that doing so would be worth the effort anyway. Why Jackrabbit/JSR-283? Because it is probably our best bet in terms of features, community, documentation and ongoing development. I'm always open to alternatives but I haven't really been given any to date. Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
