Jacopo,
You would even consider forking? This sounds more that you want to be in
control than going for the best and work together.....
I would like to propose to join the Moqui framework and when ready, use
in OFBiz the jars only as we do with other open source products.
My proposal is that Apache OFBiz will be in the future just the ERP
system based on many opensource products like birt and also Moqui....
Regards,
Hans
On 03/02/2012 01:38 PM, Jacopo Cappellato wrote:
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
