From: "Jacopo Cappellato" <jacopo.cappell...@hotwaxmedia.com>
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
