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
