Le 20/03/2012 11:48, Jacopo Cappellato a écrit :
Or alternatively we could:

1) keep it in framework
2) but remove it from the upcoming new release branch 12.04
3) and then, as a community, we could start the effort (i.e. top priority for 
upcoming contributions/commits) of defining the set of requirements needed by 
the applications to replace the existing Content framework, finalizing the 
architecture and start working all on the implementation and migration of 
existing applications: this would mean that the community will focus on this 
refactoring effort for a while (postponing any other new development to focus 
the energy)
I agree, refactoring content to separate a little more technical and functional element, it's not easier to implement JCR without a main reflexion on content.

We implement an EDM with content and an interface between document repository (file, text, sound) and content service appears needed, independently than JCR (open the plugin document engine solution :) )

Nicolas


At least in this way we could experiment if the concept of a roadmap is a 
viable options and we will not keep and distribute a component under 
development waiting to see if and when something good will come out of it.

Jacopo

On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote:

On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote:

New thread for only JCR funstion

Summary of initial discussion:

Jacoppo:
N) framework/jcr: move back into the Jackrabbit branch until the work is completed and 
can replace the existing "content framework"
Hans:
Also moving the JCR function out is not a good idea however when not improved 
in the next few months using the content manager, i would agree to a removal.
Jacoppo
Keep it mind we are preparing for the creation of the new release branch 
(12.04): this would mean that all the future releases for 12.04 will be bundled 
with an incomplete JCR/Jackrabbit integration that duplicates (but not 
replaces) the existing Component framework. This is alone a good reason for 
moving this work back to the development branch and will save a lot of future 
work in backporting features if security issues or bugs will be discovered.
IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm 
working for) are using content component in a lot of place, product, 
workeffort, project, party, custRequest, ....  to manage files, so we area 
waiting the next step of the jcr OFBiz (content) integration.
Meanwhile this second step, if jcr  was a plugin, we will use it for some new 
customer project (and maybe contribute on ;-) but not use it for older customer 
which currently works with OFBiz solution to avoid using not completely 
implement feature.
So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able 
to used it easily.

I didn't follow the details of the plans for JCR/Jackrabbit integration but as 
far as I understand it it is intended to be highly integrated with OFBiz (to 
replace Content Framework features): I am not sure how this is inline with 
Olivier's idea of a plugin, but it is an idea that can be explored. However, 
since we are still in this design phase I think it is a good idea to keep the 
component in the development branch in the meantime.

Jacopo



--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/

Reply via email to