Definitively remove beanshell from OFBiz

[Erwan de FERRIERES-2]

Hi all,

in may 2008, we decided to move from beanshell to groovy
(http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).

Since this time a lot of migration has been done, but still some
snippets are remaining in the code (mostly in screens).

What do you think of removing all the remaining bsh code, as well as
its support in OFBiz ?

Regards,

--
Erwan de FERRIERES

[Pierre Smits]

Hi all,

Reading thru the mail archive and seeing the vote result there needn't be a
new voting round. But an umbrella JIRA with underlying issues and perhaps a
new branch to work on.

I would love to see it propositioned for an upcoming release.

Regards,

Pierre Smits

2012/2/8 Erwan de FERRIERES <[hidden email]>

> Hi all,
>
> in may 2008, we decided to move from beanshell to groovy
> (
> http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell
> ).
>
> Since this time a lot of migration has been done, but still some
> snippets are remaining in the code (mostly in screens).
>
> What do you think of removing all the remaining bsh code, as well as
> its support in OFBiz ?
>
> Regards,
>
> --
> Erwan de FERRIERES
>

[Erwan de FERRIERES-2]

2012/2/8 Pierre Smits <[hidden email]>:

> Hi all,
>
> Reading thru the mail archive and seeing the vote result there needn't be a
> new voting round. But an umbrella JIRA with underlying issues and perhaps a
> new branch to work on.
>
> I would love to see it propositioned for an upcoming release.
>
> Regards,
>
> Pierre Smits
>

Yes, my concern is more about removing completely the beanshell support.
No problem for creating a new branch.


--
Erwan de FERRIERES

[Jacques Le Roux]

After almost 4 years, I can see no problems with that

Jacques

From: "Erwan de FERRIERES" <[hidden email]>

> Hi all,
>
> in may 2008, we decided to move from beanshell to groovy
> (http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
>
> Since this time a lot of migration has been done, but still some
> snippets are remaining in the code (mostly in screens).
>
> What do you think of removing all the remaining bsh code, as well as
> its support in OFBiz ?
>
> Regards,
>
> --
> Erwan de FERRIERES

[Adrian Crum-3]

It would be nice if we could come up with a way to use JSR 223 in screen
widgets and mini-language.

-Adrian

On 2/9/2012 6:31 AM, Jacques Le Roux wrote:

> After almost 4 years, I can see no problems with that
> Jacques
>
> From: "Erwan de FERRIERES" <[hidden email]>
>> Hi all,
>>
>> in may 2008, we decided to move from beanshell to groovy
>> (http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
>>
>>
>> Since this time a lot of migration has been done, but still some
>> snippets are remaining in the code (mostly in screens).
>>
>> What do you think of removing all the remaining bsh code, as well as
>> its support in OFBiz ?
>>
>> Regards,
>>
>> --
>> Erwan de FERRIERES

[Erwan de FERRIERES-2]

2012/2/12 Adrian Crum <[hidden email]>:
> It would be nice if we could come up with a way to use JSR 223 in screen
> widgets and mini-language.
>
> -Adrian
Excellent idea ! I've starting reading the specs, and it seems to be
very interesting.

Some links:
* http://www.jcp.org/en/jsr/detail?id=223
* http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/
* (french) integrating jsr223 in jmeter:
http://blog.zenika.com/index.php?post/2009/07/29/INTEGRATION-DU-SUPPORT-DU-JSR223-DANS-JMETER


--
Erwan de FERRIERES

[Erwan de FERRIERES]

Le 12/02/2012 20:43, Adrian Crum a écrit :
> It would be nice if we could come up with a way to use JSR 223 in screen
> widgets and mini-language.

Adrian,

would this mean that we'll be moving from
groovy.lang.Script
to
ScriptEngineManager and ScriptEngine ?

Do you think this would be a big task to accomplish this migration ?

Regards,

>
> -Adrian
>
> On 2/9/2012 6:31 AM, Jacques Le Roux wrote:
>> After almost 4 years, I can see no problems with that
>> Jacques
>>
>> From: "Erwan de FERRIERES" <[hidden email]>
>>> Hi all,
>>>
>>> in may 2008, we decided to move from beanshell to groovy
>>> (http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
>>>
>>>
>>> Since this time a lot of migration has been done, but still some
>>> snippets are remaining in the code (mostly in screens).
>>>
>>> What do you think of removing all the remaining bsh code, as well as
>>> its support in OFBiz ?
>>>
>>> Regards,
>>>
>>> --
>>> Erwan de FERRIERES
>

--
Erwan de FERRIERES
www.nereide.biz

[Jacopo Cappellato-4]

Implementing JSR-223 should be rather easy but if I am not wrong it would prevent the ability to cache the scripts (task that is currently done in org.ofbiz.base.util.GroovyUtil, that is using the the more flexible GroovyClassLoader mechanism); we could probably use the javax.script.Compilable interface but I am not sure...
One advantage of JSR-223 would be that we could dynamically select the script engine based on the (for example) file extension without the need to maintain several classes like GroovyUtil, BsfUtil etc...
The idea would be that, instead of having a GroovyUtil class we could have a generic ScriptUtil class with code like the following:

        ScriptEngineManager manager = new ScriptEngineManager();
        ScriptEngine scriptEngine = manager.getEngineByExtension(fileExtension);
        Object result = scriptEngine.eval(scriptFileReader, scriptContext);

and this code would be generic and could be used to plug in all the scripting engines that support JSR-223.

However doing this in OFBiz would mean that we have to refactor all the code that is currently using the various <script>Util classes and in my opinion a simpler path (that is inline with Erwan's proposal to convert all remaining beanshell snippets to Groovy and then deprecate or remove BshUtil) would be:

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)



On Feb 27, 2012, at 3:53 PM, Erwan de FERRIERES wrote:

> Le 12/02/2012 20:43, Adrian Crum a écrit :
>> It would be nice if we could come up with a way to use JSR 223 in screen
>> widgets and mini-language.
>
> Adrian,
>
> would this mean that we'll be moving from
> groovy.lang.Script
> to
> ScriptEngineManager and ScriptEngine ?
>
> Do you think this would be a big task to accomplish this migration ?
>
> Regards,
>
>>
>> -Adrian
>>
>> On 2/9/2012 6:31 AM, Jacques Le Roux wrote:
>>> After almost 4 years, I can see no problems with that
>>> Jacques
>>>
>>> From: "Erwan de FERRIERES" <[hidden email]>
>>>> Hi all,
>>>>
>>>> in may 2008, we decided to move from beanshell to groovy
>>>> (http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
>>>>
>>>>
>>>> Since this time a lot of migration has been done, but still some
>>>> snippets are remaining in the code (mostly in screens).
>>>>
>>>> What do you think of removing all the remaining bsh code, as well as
>>>> its support in OFBiz ?
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Erwan de FERRIERES
>>
>
>
> --
> Erwan de FERRIERES
> www.nereide.biz

[Adrian Crum-3]

As far as I know, most scripting engines have some sort of embedded
cache. The problem will be that we can't clear the embedded cache like
we can with our own cache implementation. I don't see that as a show
stopper - it's mostly inconvenient.

I can help out with the conversion. I don't think the task will be that
hard.

Regarding a slimmed down framework, I proposed one some time ago:

https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision

and that document was in response to David's proposal to base OFBiz on
Moqui (another option).

-Adrian


On 3/1/2012 8:53 AM, Jacopo Cappellato wrote:

> Implementing JSR-223 should be rather easy but if I am not wrong it would prevent the ability to cache the scripts (task that is currently done in org.ofbiz.base.util.GroovyUtil, that is using the the more flexible GroovyClassLoader mechanism); we could probably use the javax.script.Compilable interface but I am not sure...
> One advantage of JSR-223 would be that we could dynamically select the script engine based on the (for example) file extension without the need to maintain several classes like GroovyUtil, BsfUtil etc...
> The idea would be that, instead of having a GroovyUtil class we could have a generic ScriptUtil class with code like the following:
>
>          ScriptEngineManager manager = new ScriptEngineManager();
>          ScriptEngine scriptEngine = manager.getEngineByExtension(fileExtension);
>          Object result = scriptEngine.eval(scriptFileReader, scriptContext);
>
> and this code would be generic and could be used to plug in all the scripting engines that support JSR-223.
>
> However doing this in OFBiz would mean that we have to refactor all the code that is currently using the various<script>Util classes and in my opinion a simpler path (that is inline with Erwan's proposal to convert all remaining beanshell snippets to Groovy and then deprecate or remove BshUtil) would be:
>
> 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)
>
>
>
> On Feb 27, 2012, at 3:53 PM, Erwan de FERRIERES wrote:
>
>> Le 12/02/2012 20:43, Adrian Crum a écrit :
>>> It would be nice if we could come up with a way to use JSR 223 in screen
>>> widgets and mini-language.
>> Adrian,
>>
>> would this mean that we'll be moving from
>> groovy.lang.Script
>> to
>> ScriptEngineManager and ScriptEngine ?
>>
>> Do you think this would be a big task to accomplish this migration ?
>>
>> Regards,
>>
>>> -Adrian
>>>
>>> On 2/9/2012 6:31 AM, Jacques Le Roux wrote:
>>>> After almost 4 years, I can see no problems with that
>>>> Jacques
>>>>
>>>> From: "Erwan de FERRIERES"<[hidden email]>
>>>>> Hi all,
>>>>>
>>>>> in may 2008, we decided to move from beanshell to groovy
>>>>> (http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
>>>>>
>>>>>
>>>>> Since this time a lot of migration has been done, but still some
>>>>> snippets are remaining in the code (mostly in screens).
>>>>>
>>>>> What do you think of removing all the remaining bsh code, as well as
>>>>> its support in OFBiz ?
>>>>>
>>>>> Regards,
>>>>>
>>>>> --
>>>>> Erwan de FERRIERES
>>
>> --
>> Erwan de FERRIERES
>> www.nereide.biz

[Jacopo Cappellato-4]

The document is interesting and I agree with the approach in general.
I don't agree, but this is a small detail, with the assertion that "currency" should be part of a framework: I can think of several applications not dealing with money :-)
And if we want to design a "framework for ERP applications" then we could have some additional pieces (like Geos, Uoms, Currencies)... but this would be more a "common" base to ERP applications.
I like the idea of "one component" framework: at that point it would be easier to deploy and we could use an external tomcat as the default setup (no more embedded catalina).
I also think that the "official OFBiz ERP" (i.e. the features currently in the "applications" folder) should also be implemented by *one* application/component: based on naming conventions and patterns to simplify customizations and reuse but still one application where features are hidden thru permissions.

But this is for OFBiz 2.0, nice to discuss, but my idea for a lightweight framework was less revolutionary and could be considered as a preparation step in the direction of the new OFBiz: cutting down old branches and unused code in order to have a smaller system to refactor according to the new vision. At that point, with a cleaner ground, we could better plan the next step: implementing a new framework or considering other options (e.g. Moqui) or even keeping what we have

Jacopo


On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:

> As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear the embedded cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient.
>
> I can help out with the conversion. I don't think the task will be that hard.
>
> Regarding a slimmed down framework, I proposed one some time ago:
>
> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>
> and that document was in response to David's proposal to base OFBiz on Moqui (another option).
>
> -Adrian
>
>
> On 3/1/2012 8:53 AM, Jacopo Cappellato wrote:
>> Implementing JSR-223 should be rather easy but if I am not wrong it would prevent the ability to cache the scripts (task that is currently done in org.ofbiz.base.util.GroovyUtil, that is using the the more flexible GroovyClassLoader mechanism); we could probably use the javax.script.Compilable interface but I am not sure...
>> One advantage of JSR-223 would be that we could dynamically select the script engine based on the (for example) file extension without the need to maintain several classes like GroovyUtil, BsfUtil etc...
>> The idea would be that, instead of having a GroovyUtil class we could have a generic ScriptUtil class with code like the following:
>>
>>         ScriptEngineManager manager = new ScriptEngineManager();
>>         ScriptEngine scriptEngine = manager.getEngineByExtension(fileExtension);
>>         Object result = scriptEngine.eval(scriptFileReader, scriptContext);
>>
>> and this code would be generic and could be used to plug in all the scripting engines that support JSR-223.
>>
>> However doing this in OFBiz would mean that we have to refactor all the code that is currently using the various<script>Util classes and in my opinion a simpler path (that is inline with Erwan's proposal to convert all remaining beanshell snippets to Groovy and then deprecate or remove BshUtil) would be:
>>
>> 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)
>>
>>
>>
>> On Feb 27, 2012, at 3:53 PM, Erwan de FERRIERES wrote:
>>
>>> Le 12/02/2012 20:43, Adrian Crum a écrit :
>>>> It would be nice if we could come up with a way to use JSR 223 in screen
>>>> widgets and mini-language.
>>> Adrian,
>>>
>>> would this mean that we'll be moving from
>>> groovy.lang.Script
>>> to
>>> ScriptEngineManager and ScriptEngine ?
>>>
>>> Do you think this would be a big task to accomplish this migration ?
>>>
>>> Regards,
>>>
>>>> -Adrian
>>>>
>>>> On 2/9/2012 6:31 AM, Jacques Le Roux wrote:
>>>>> After almost 4 years, I can see no problems with that
>>>>> Jacques
>>>>>
>>>>> From: "Erwan de FERRIERES"<[hidden email]>
>>>>>> Hi all,
>>>>>>
>>>>>> in may 2008, we decided to move from beanshell to groovy
>>>>>> (http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
>>>>>>
>>>>>>
>>>>>> Since this time a lot of migration has been done, but still some
>>>>>> snippets are remaining in the code (mostly in screens).
>>>>>>
>>>>>> What do you think of removing all the remaining bsh code, as well as
>>>>>> its support in OFBiz ?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> --
>>>>>> Erwan de FERRIERES
>>>
>>> --
>>> Erwan de FERRIERES
>>> www.nereide.biz
>

[Adrian Crum-3]

I included currency in the framework because i18n libraries the
framework is based on will include it.

A "framework for ERP applications" would be built on the framework I
proposed - I mentioned that in the document. In my mind, things should
be modular, instead of the monolithic design we have now. So, geos would
be a separate component that uses the framework - just like scripting is
a separate component. The framework plus a selection of additional
components could comprise a "framework for ERP applications." I believe
this approach will broaden the user base because we will eliminate the
"all or nothing" approach used now.

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.

The workflow I pictured was to introduce a new component and build from
the ground up. Initially there will be some code duplication due to
parallel development paths, but once the new component is finished,
other OFBiz artifacts can be updated to use it and any excess can be
removed. In other words, the code removal is motivated by the fact that
it is no longer needed.

-Adrian

On 3/1/2012 10:15 AM, Jacopo Cappellato wrote:

> The document is interesting and I agree with the approach in general.
> I don't agree, but this is a small detail, with the assertion that "currency" should be part of a framework: I can think of several applications not dealing with money :-)
> And if we want to design a "framework for ERP applications" then we could have some additional pieces (like Geos, Uoms, Currencies)... but this would be more a "common" base to ERP applications.
> I like the idea of "one component" framework: at that point it would be easier to deploy and we could use an external tomcat as the default setup (no more embedded catalina).
> I also think that the "official OFBiz ERP" (i.e. the features currently in the "applications" folder) should also be implemented by *one* application/component: based on naming conventions and patterns to simplify customizations and reuse but still one application where features are hidden thru permissions.
>
> But this is for OFBiz 2.0, nice to discuss, but my idea for a lightweight framework was less revolutionary and could be considered as a preparation step in the direction of the new OFBiz: cutting down old branches and unused code in order to have a smaller system to refactor according to the new vision. At that point, with a cleaner ground, we could better plan the next step: implementing a new framework or considering other options (e.g. Moqui) or even keeping what we have
>
> Jacopo
>
>
> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>
>> As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear the embedded cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient.
>>
>> I can help out with the conversion. I don't think the task will be that hard.
>>
>> Regarding a slimmed down framework, I proposed one some time ago:
>>
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>
>> and that document was in response to David's proposal to base OFBiz on Moqui (another option).
>>
>> -Adrian
>>
>>
>> On 3/1/2012 8:53 AM, Jacopo Cappellato wrote:
>>> Implementing JSR-223 should be rather easy but if I am not wrong it would prevent the ability to cache the scripts (task that is currently done in org.ofbiz.base.util.GroovyUtil, that is using the the more flexible GroovyClassLoader mechanism); we could probably use the javax.script.Compilable interface but I am not sure...
>>> One advantage of JSR-223 would be that we could dynamically select the script engine based on the (for example) file extension without the need to maintain several classes like GroovyUtil, BsfUtil etc...
>>> The idea would be that, instead of having a GroovyUtil class we could have a generic ScriptUtil class with code like the following:
>>>
>>>          ScriptEngineManager manager = new ScriptEngineManager();
>>>          ScriptEngine scriptEngine = manager.getEngineByExtension(fileExtension);
>>>          Object result = scriptEngine.eval(scriptFileReader, scriptContext);
>>>
>>> and this code would be generic and could be used to plug in all the scripting engines that support JSR-223.
>>>
>>> However doing this in OFBiz would mean that we have to refactor all the code that is currently using the various<script>Util classes and in my opinion a simpler path (that is inline with Erwan's proposal to convert all remaining beanshell snippets to Groovy and then deprecate or remove BshUtil) would be:
>>>
>>> 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)
>>>
>>>
>>>
>>> On Feb 27, 2012, at 3:53 PM, Erwan de FERRIERES wrote:
>>>
>>>> Le 12/02/2012 20:43, Adrian Crum a écrit :
>>>>> It would be nice if we could come up with a way to use JSR 223 in screen
>>>>> widgets and mini-language.
>>>> Adrian,
>>>>
>>>> would this mean that we'll be moving from
>>>> groovy.lang.Script
>>>> to
>>>> ScriptEngineManager and ScriptEngine ?
>>>>
>>>> Do you think this would be a big task to accomplish this migration ?
>>>>
>>>> Regards,
>>>>
>>>>> -Adrian
>>>>>
>>>>> On 2/9/2012 6:31 AM, Jacques Le Roux wrote:
>>>>>> After almost 4 years, I can see no problems with that
>>>>>> Jacques
>>>>>>
>>>>>> From: "Erwan de FERRIERES"<[hidden email]>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> in may 2008, we decided to move from beanshell to groovy
>>>>>>> (http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
>>>>>>>
>>>>>>>
>>>>>>> Since this time a lot of migration has been done, but still some
>>>>>>> snippets are remaining in the code (mostly in screens).
>>>>>>>
>>>>>>> What do you think of removing all the remaining bsh code, as well as
>>>>>>> its support in OFBiz ?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> --
>>>>>>> Erwan de FERRIERES
>>>> --
>>>> Erwan de FERRIERES
>>>> www.nereide.biz

[Jacopo Cappellato-4]

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

[Adrian Crum-3]

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

[Jacopo Cappellato-4]

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

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

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>
>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
>
>

[hans_bakker]

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" <[hidden email]>
>> 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
>>
>>

[Jacopo Cappellato-4]

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" <[hidden email]>
>>> 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
>>>
>>>
>

[hans_bakker]

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"<[hidden email]>
>>>> 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
>>>>

[Jacopo Cappellato-4]

On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:

> Jacopo,
>
> You would even consider forking? This sounds more that you want to be in control than going for the best and work together.....

me?

> 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.

As I said, this is something to consider for sure... but in the same time we have to consider all options: currently the OFBiz community is about the development of a framework and ERP system and if we change this goal it will be a big decision, so we have to consider all the pros and cons.

>
> 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

[hans_bakker]

Jacopo,

please read in the original message.....you took it away here.....
you wrote:
---------------------------------------------------------
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?
---------------------------------------------------------

That you even consider this as the first option....not sound good......

Regards



On 03/02/2012 02:05 PM, Jacopo Cappellato wrote:

> On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:
>
>> Jacopo,
>>
>> You would even consider forking? This sounds more that you want to be in control than going for the best and work together.....
> me?
>
>> 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.
> As I said, this is something to consider for sure... but in the same time we have to consider all options: currently the OFBiz community is about the development of a framework and ERP system and if we change this goal it will be a big decision, so we have to consider all the pros and cons.
>
>> 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