Before even start to plan a new framework we should indeed at least carefully review what David did in Moqui. I actually already spent some time reviewing some parts of it and I will continue for sure as I am very interested in all the work that David does. If the OFBiz community will ever consider to adopt Moqui as the new framework then a lot of decision will have to be taken: forking Moqui and import its source files in the OFBiz svn? Use Moqui releases as "external jars" and have the OFBiz community only work on the ERP part? Collaborate with the Moqui community to get the features that we need in OFBiz? A lot of questions for the future... but in the meantime I agree with Jacques that we can take small steps to improve what we already have: agree on a plan (e.g. simplifying/cleaning the framework in preparation of a future evolution, Moqui or something else) and then stick to it moving at small steps in the same direction.
Jacopo On Mar 2, 2012, at 6:59 AM, Hans Bakker wrote: > Shouldn't we considering replacing the ofbiz framework with th Moqui > framework? > > David (with Andy) created the OFBiz framework, learned from it and created > Moqui using this knowledge. > > Why not have all people interested refactoring the OFBiz framework join the > Moqui project? > > David, what do you think? > > > Regards, > Hans > > > On 03/02/2012 10:31 AM, Jacques Le Roux wrote: >> From: "Jacopo Cappellato" <[email protected]> >>> I don't think it will be easy and actually it may be unfeasible but I see >>> some good reasons for hope: >>> >>> * the general discussion/vote would involve all committers and not only PMC >>> members: everyone would be involved in the decision >>> and in the responsibilities/consequences around it >>> * our committers group is made of clever persons that know we are all >>> playing on top of a system that is bigger than us, that is >>> very complex and has been built thanks to the visions and great >>> ideas/skills of others; we have to make sure we do not ruin what >>> we are asked to maintain and improve and, with such a big and complex >>> beast, working together as a group is the only responsible >>> way of achieving this difficult task... on the other hand continuing to >>> think as individuals with our own personal goals and ideas >>> will make a mess of this project soon >> >> I'd be very happy to see some sense of responsability to increase in the >> community. And I have the feeling that it's the case. We >> communicate better, and better respect each other ideas and ways. This said, >> there are huges task ahead... >> >> As I said in another email, I'm more for the step by step approach than to >> try a dramatic change, ie more evolution thant >> revolution >> >> PS: to be more clear, when I speak about "step by step approach" I think >> about something like this part of a previous email: >> >>> 1) migrate the remaining Beanshell snippets to Groovy >>> 2) deprecate or remove (I see a lot of value in having lighter framework >>> [*]) Beashell support (and other artifacts related to old/unused script >>> engines) >>> 3) (optional, something for the future) refactor the GroovyUtil class (and >>> code that is using it) to be generic (ScriptUtil) and convert all the >>> calling code to use it in a Groovy unaware way; this will implement the >>> JSR-223 >>> >>> In this way, when we will work on #3 we could concentrate only on migration >>> of groovy classes rather than having to cope with several other >>> technologies (removed at #2) >>> >>> Kind regards, >>> >>> Jacopo >>> >>> [*] In my opinion one of the main big steps that the OFBiz project should >>> consider is to greatly slim down the framework and only support the >>> technology we really need (picking the best for each task); then with a >>> much smaller codebase, we will be able to quickly improve the framework >>> (less code to maintain etc...) to be compliant with new standards etc.. >>> (e.g. JSR-223). For example in this context: ideally the OFBiz project >>> should have all the scripts implemented in Groovy (one technology) and a >>> simple way to integrate other scripting languages; we could achieve this >>> implementing JSR-223 so that even the OFBiz code would be using >>> javax.script.* rather than groovy.* packages OR it would be also fine if we >>> would still be using groovy.* packages but in a clean way (e.g. all calling >>> code could use interfaces to hide Groovy specific code) so that adding a >>> new script engine would be easy (but the support of the new script engine >>> will not be included in the project to keep it light and focused) >> >> Then, when done (I mean not only this part but also some needeeed others), >> an approach like suggested by Adrian could be adopted... >> >> My 2cts >> >> Jacques >> >> >>> >>> Jacopo >>> >>> On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote: >>> >>>> You are a lot more optimistic than I am. Despite the best efforts of PMC >>>> members to provide advice/guidance/suggestions, >>>> committers still do what they please. It's worth a try, but I don't have >>>> much hope for success. >>>> >>>> -Adrian >>>> >>>> On 3/1/2012 1:48 PM, Jacopo Cappellato wrote: >>>>> On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote: >>>>> >>>>>> I understand the workflow you are suggesting - cut down the size of the >>>>>> existing framework and then switch to something else. >>>>>> In an ideal world we could do that. Unfortunately, we have a lot of >>>>>> committers who believe more is better, so while we're >>>>>> cutting down in one area, someone else will be adding code in another >>>>>> area. >>>>> Yes, I know what you mean: I still think that, if the goal is clear and >>>>> the strategy makes sense (e.g. "simplify/standardize the >>>>> tools used, for example migrate everything from bsh to groovy, and then >>>>> slim down the current framework to the bare minimum >>>>> technologies used by the official applications in order to simplify and >>>>> renew the code base") we could try to work to get a >>>>> majority approval and a shared strategy and then everyone will have to >>>>> stick to the plan and help to implement it... i.e. >>>>> working as a community rather than as individual with commit rights and >>>>> different visions. >>>>> >>>>> Jacopo >>> >>> >
