Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished Re 3: draft up requirements for content framework replacement +1
Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato < [email protected]> het volgende: > 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) > > 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 > > > >
