Definitively remove beanshell from OFBiz

[Jacopo Cappellato-4]

Yes, I know what I wrote.
My question was about your sentence:

"This sounds more that you want to be in control than going for the best and work together."

and I was asking you if the "you" word in it was referred to me or to "the community" in general... now you have clarified that it was referred to me and you are accusing me to be unfair and look for the power. Got it.

I will reply to your email later.

Jacopo

On Mar 2, 2012, at 8:20 AM, Hans Bakker wrote:

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

[hans_bakker]

Jacopo,

no reply needed Jacopo......My statement just was that you consider
forking of moqui as a first option what i think is rather strange....

Regards,
Hans

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

> Yes, I know what I wrote.
> My question was about your sentence:
>
> "This sounds more that you want to be in control than going for the best and work together."
>
> and I was asking you if the "you" word in it was referred to me or to "the community" in general... now you have clarified that it was referred to me and you are accusing me to be unfair and look for the power. Got it.
>
> I will reply to your email later.
>
> Jacopo
>
> On Mar 2, 2012, at 8:20 AM, Hans Bakker wrote:
>
>> 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

[Jacopo Cappellato-4]

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

> Jacopo,
>
> You would even consider forking?

From Wikipedia [*]:

"[...] More recently, distributed revision control (DVCS) tools have popularised a less emotive use of the term "fork", blurring the distinction with "branch". With a DVCS such as Mercurial or Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your changes integrated with the main repository. Sites such as Github, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced."

In order of preference (descending), here are the options I see for the future of the OFBiz framework:

1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then release it separately from the Apache OFBiz ERP
2) greatly clean up and improve the existing framework (I was not sure if this could go at #1)
3) if the above will not be possible (frankly speaking, in the committers group, apart from David, none of us ever implemented with success an open source framework) we should also consider to drop the existing code and have our community focusing on the ERP part (as Hans seems to advocate); at this point Moqui would be the most natural choice; if we will ever go with this path a great exchange of information will have to happen between the two projects: for example OFBiz will probably have to ask the Moqui framework to evolve some of its features; given the current nature of the Moqui project, I doubt that the OFBiz committers will be ever invited as committers there; if Moqui will be our choice, I see two possibilities:
3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be possible if Moqui release will have all the features we need (and if Moqui community will be interested in getting contribution to evolve in the direction required by OFBzi)
3.b) if 3.a will not be possible because OFBiz will need some features that Moqui community will not consider as a good fit for Moqui, then, under the guidance and bless of David, we could work on a fork: get the code from a Moqui release, import in our repository and add to it, in a controlled way, the features we need; of course this should be always kept as close as possible to the original code; we could synch our custom code with every new Moqui release; I was not thinking about *stealing* code to Moqui and the fact that David is both the founder of OFBiz and of Moqui and he is both in the OFBiz PMC and the leader of the Moqui project will definitely facilitate this; but it will be still an ugly solution but for example when you said: "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...." you are actually implying that the ERP applications will be able to use Birt... but this requires some sort of framework and what would you do if Moqui will not think that Birt is a good fit for them?
4) if Moqui will not be a good option we may consider other frameworks (?), but it will be difficult, or continue with what we have

Jacopo



[*]: http://en.wikipedia.org/wiki/Fork_(software_development)

[Adrian Crum-3]

On 3/2/2012 8:28 AM, Jacopo Cappellato wrote:
> In order of preference (descending), here are the options I see for the future of the OFBiz framework:
>
> 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then release it separately from the Apache OFBiz ERP

This is the approach I prefer.

> 2) greatly clean up and improve the existing framework (I was not sure if this could go at #1)

I agree this is less preferable, but if we decide to go this route I
will help.

> 3) if the above will not be possible (frankly speaking, in the committers group, apart from David, none of us ever implemented with success an open source framework) we should also consider to drop the existing code and have our community focusing on the ERP part (as Hans seems to advocate); at this point Moqui would be the most natural choice; if we will ever go with this path a great exchange of information will have to happen between the two projects: for example OFBiz will probably have to ask the Moqui framework to evolve some of its features; given the current nature of the Moqui project, I doubt that the OFBiz committers will be ever invited as committers there; if Moqui will be our choice, I see two possibilities:

Some of us have implemented successful ERP frameworks, just not open
source ones. Also keep in mind that the OFBiz framework we have today
includes designs from many contributors. So, let's make sure we give
credit where credit is due, without diminishing David and Andrew's role.

-Adrian

[Jacopo Cappellato-4]

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.

Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
I will commit my code changes today.

Regards,

Jacopo

[Bruno Busco]

Jacopo,
I would go, or at least, deeply consider option:

3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be
possible if Moqui release will have all the features we need (and if Moqui
community will be interested in getting contribution to evolve in the
direction required by OFBzi)

I think that David will be more than interested in evaluating every feature
needed by OFBiz.
He has already started the mantle and crust projects that, on top of the
Moqui framework, should be something like a reworked OFBiz.

-Bruno

2012/3/2 Jacopo Cappellato <[hidden email]>

>
> On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:
>
> > Jacopo,
> >
> > You would even consider forking?
>
> From Wikipedia [*]:
>
> "[...] More recently, distributed revision control (DVCS) tools have
> popularised a less emotive use of the term "fork", blurring the distinction
> with "branch". With a DVCS such as Mercurial or Git, the normal way to
> contribute to a project is to first branch the repository, and later seek
> to have your changes integrated with the main repository. Sites such as
> Github, Bitbucket and Launchpad provide free DVCS hosting expressly
> supporting independent branches, such that the technical, social and
> financial barriers to forking a source code repository are massively
> reduced."
>
> In order of preference (descending), here are the options I see for the
> future of the OFBiz framework:
>
> 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community;
> then release it separately from the Apache OFBiz ERP
> 2) greatly clean up and improve the existing framework (I was not sure if
> this could go at #1)
> 3) if the above will not be possible (frankly speaking, in the committers
> group, apart from David, none of us ever implemented with success an open
> source framework) we should also consider to drop the existing code and
> have our community focusing on the ERP part (as Hans seems to advocate); at
> this point Moqui would be the most natural choice; if we will ever go with
> this path a great exchange of information will have to happen between the
> two projects: for example OFBiz will probably have to ask the Moqui
> framework to evolve some of its features; given the current nature of the
> Moqui project, I doubt that the OFBiz committers will be ever invited as
> committers there; if Moqui will be our choice, I see two possibilities:
> 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be
> possible if Moqui release will have all the features we need (and if Moqui
> community will be interested in getting contribution to evolve in the
> direction required by OFBzi)
> 3.b) if 3.a will not be possible because OFBiz will need some features
> that Moqui community will not consider as a good fit for Moqui, then, under
> the guidance and bless of David, we could work on a fork: get the code from
> a Moqui release, import in our repository and add to it, in a controlled
> way, the features we need; of course this should be always kept as close as
> possible to the original code; we could synch our custom code with every
> new Moqui release; I was not thinking about *stealing* code to Moqui and
> the fact that David is both the founder of OFBiz and of Moqui and he is
> both in the OFBiz PMC and the leader of the Moqui project will definitely
> facilitate this; but it will be still an ugly solution but for example when
> you said: "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...."
> you are actually implying that the ERP applications will be able to use
> Birt... but this requires some sort of framework and what would you do if
> Moqui will not think that Birt is a good fit for them?
> 4) if Moqui will not be a good option we may consider other frameworks
> (?), but it will be difficult, or continue with what we have
>
> Jacopo
>
>
>
> [*]: http://en.wikipedia.org/wiki/Fork_(software_development)

[Jacopo Cappellato-4]

My changes are in commit 1296762

Help with reviews and tests will be very much appreciated.

Jacopo

On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:

>
> 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.
>
> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
> I will commit my code changes today.
>
> Regards,
>
> Jacopo
>
>
>

[Adrian Crum-3]

The code changes tested fine.

I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think that?

-Adrian


On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:

> My changes are in commit 1296762
>
> Help with reviews and tests will be very much appreciated.
>
> Jacopo
>
> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>
>> 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.
>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>> I will commit my code changes today.
>>
>> Regards,
>>
>> Jacopo
>>
>>
>>

[Jacques Le Roux]

I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean it's
the idea and what Jacopo said already.

I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...

Jacques

From: "Adrian Crum" <[hidden email]>

> The code changes tested fine.
>
> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think that?
>
> -Adrian
>
>
> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>> My changes are in commit 1296762
>>
>> Help with reviews and tests will be very much appreciated.
>>
>> Jacopo
>>
>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>
>>> 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.
>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>> I will commit my code changes today.
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>>
>>>

[Adrian Crum-3]

Groovy supports JSR-223, so there is no reason to treat it differently.
My question has nothing to do with which scripting engine is supplied
with OFBiz.

-Adrian

On 3/4/2012 8:43 PM, Jacques Le Roux wrote:

> I don't want to interfer with Jacopo's answer, but I guess it's
> because Groovy will be implemented OOTB. The others could be but
> Groovy is already part of the framework (the inital subject from Erwan
> was to completely remove BeanShell OOTB usage), I mean it's the idea
> and what Jacopo said already.
>
> I second this idea. Everybody can use her/his preferred scripting
> language in custom projects. But using only one language OOTB seems to
> be common sense. We chose groovy...
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>> The code changes tested fine.
>>
>> I noticed in your code comments that Groovy should be handled
>> independently from other scripting languages. Why do you think that?
>>
>> -Adrian
>>
>>
>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>> My changes are in commit 1296762
>>>
>>> Help with reviews and tests will be very much appreciated.
>>>
>>> Jacopo
>>>
>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>
>>>> 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.
>>>> Adrian, FYI I am enhancing some of the existing framework code that
>>>> uses the GroovyUtil class to simplify this task.
>>>> I will commit my code changes today.
>>>>
>>>> Regards,
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>

[Jacques Le Roux]

I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
So I thought at some point you have to check which language wich is used?

Like in
+        if ("groovy".equals(language)) {
+            if (scriptClass == null) {
+                scriptClass = ScriptUtil.parseScript(language, script);
+            }
+            if (scriptClass != null) {
+                result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
+            }
+        } else if ("bsh".equals(language)) {
+            result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
+        }

In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?

Jacques

From: "Adrian Crum" <[hidden email]>

> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting engine
> is supplied with OFBiz.
>
> -Adrian
>
> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but
>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean
>> it's the idea and what Jacopo said already.
>>
>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB
>> seems to be common sense. We chose groovy...
>>
>> Jacques
>>
>> From: "Adrian Crum" <[hidden email]>
>>> The code changes tested fine.
>>>
>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think
>>> that?
>>>
>>> -Adrian
>>>
>>>
>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>> My changes are in commit 1296762
>>>>
>>>> Help with reviews and tests will be very much appreciated.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>
>>>>> 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.
>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>> I will commit my code changes today.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>

[Adrian Crum-3]

No, the whole idea is to delegate that decision making to the
javax.script package.

-Adrian

On 3/4/2012 9:27 PM, Jacques Le Roux wrote:

> I must says I only cursorily reviewed the code Jacopo committed and
> did not look into JSR-223 details.
> So I thought at some point you have to check which language wich is used?
>
> Like in
> +        if ("groovy".equals(language)) {
> +            if (scriptClass == null) {
> +                scriptClass = ScriptUtil.parseScript(language, script);
> +            }
> +            if (scriptClass != null) {
> +                result = InvokerHelper.createScript(scriptClass,
> GroovyUtil.getBinding(inputMap)).run();
> +            }
> +        } else if ("bsh".equals(language)) {
> +            result = BshUtil.eval(script,
> UtilMisc.makeMapWritable(inputMap));
> +        }
>
> In other words from Jacopo's code here, it seems you have to
> differentiate how scritps are parsed?
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>> Groovy supports JSR-223, so there is no reason to treat it
>> differently. My question has nothing to do with which scripting engine
>> is supplied with OFBiz.
>>
>> -Adrian
>>
>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>> I don't want to interfer with Jacopo's answer, but I guess it's
>>> because Groovy will be implemented OOTB. The others could be but
>>> Groovy is already part of the framework (the inital subject from
>>> Erwan was to completely remove BeanShell OOTB usage), I mean
>>> it's the idea and what Jacopo said already.
>>>
>>> I second this idea. Everybody can use her/his preferred scripting
>>> language in custom projects. But using only one language OOTB
>>> seems to be common sense. We chose groovy...
>>>
>>> Jacques
>>>
>>> From: "Adrian Crum" <[hidden email]>
>>>> The code changes tested fine.
>>>>
>>>> I noticed in your code comments that Groovy should be handled
>>>> independently from other scripting languages. Why do you think
>>>> that?
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>> My changes are in commit 1296762
>>>>>
>>>>> Help with reviews and tests will be very much appreciated.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>
>>>>>> 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.
>>>>>> Adrian, FYI I am enhancing some of the existing framework code
>>>>>> that uses the GroovyUtil class to simplify this task.
>>>>>> I will commit my code changes today.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>>>

[Jacopo Cappellato-4]

I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent on ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no spaces) followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on existing scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify them to be compatible with the convention. I intentionally didn't focus on this second step.

Jacopo

On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:

> I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
> So I thought at some point you have to check which language wich is used?
>
> Like in
> +        if ("groovy".equals(language)) {
> +            if (scriptClass == null) {
> +                scriptClass = ScriptUtil.parseScript(language, script);
> +            }
> +            if (scriptClass != null) {
> +                result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
> +            }
> +        } else if ("bsh".equals(language)) {
> +            result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
> +        }
>
> In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting engine
>> is supplied with OFBiz.
>>
>> -Adrian
>>
>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but
>>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean
>>> it's the idea and what Jacopo said already.
>>>
>>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB
>>> seems to be common sense. We chose groovy...
>>>
>>> Jacques
>>>
>>> From: "Adrian Crum" <[hidden email]>
>>>> The code changes tested fine.
>>>>
>>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think
>>>> that?
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>> My changes are in commit 1296762
>>>>>
>>>>> Help with reviews and tests will be very much appreciated.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>
>>>>>> 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.
>>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>>> I will commit my code changes today.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>>>

[Jacopo Cappellato-4]

On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:

> The code changes tested fine.
>
> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think that?

First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.

The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:

* ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
* the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...

We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.

Jacopo

>
> -Adrian
>
>
> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>> My changes are in commit 1296762
>>
>> Help with reviews and tests will be very much appreciated.
>>
>> Jacopo
>>
>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>
>>> 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.
>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>> I will commit my code changes today.
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>>
>>>

[Adrian Crum-3]

I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a string
followed by a colon can lead to errors.

-Adrian

On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:

> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent on ScriptUtil class.
> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no spaces) followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on existing scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify them to be compatible with the convention. I intentionally didn't focus on this second step.
>
> Jacopo
>
> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>
>> I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
>> So I thought at some point you have to check which language wich is used?
>>
>> Like in
>> +        if ("groovy".equals(language)) {
>> +            if (scriptClass == null) {
>> +                scriptClass = ScriptUtil.parseScript(language, script);
>> +            }
>> +            if (scriptClass != null) {
>> +                result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
>> +            }
>> +        } else if ("bsh".equals(language)) {
>> +            result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
>> +        }
>>
>> In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?
>>
>> Jacques
>>
>> From: "Adrian Crum"<[hidden email]>
>>> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting engine
>>> is supplied with OFBiz.
>>>
>>> -Adrian
>>>
>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but
>>>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean
>>>> it's the idea and what Jacopo said already.
>>>>
>>>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB
>>>> seems to be common sense. We chose groovy...
>>>>
>>>> Jacques
>>>>
>>>> From: "Adrian Crum"<[hidden email]>
>>>>> The code changes tested fine.
>>>>>
>>>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think
>>>>> that?
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>> My changes are in commit 1296762
>>>>>>
>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>
>>>>>>> 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.
>>>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>>>> I will commit my code changes today.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
>>>>>>>

[Adrian Crum-3]

It seems to me if there is a security issue using Groovy, then there
would be an issue using any scripting language.

Why can't we put the "friendly methods" in the context, so all scripting
languages can use them?

-Adrian

On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:

> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>
>> The code changes tested fine.
>>
>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think that?
> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>
> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>
> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>
> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>
> Jacopo
>
>> -Adrian
>>
>>
>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>> My changes are in commit 1296762
>>>
>>> Help with reviews and tests will be very much appreciated.
>>>
>>> Jacopo
>>>
>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>
>>>> 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.
>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>> I will commit my code changes today.
>>>>
>>>> Regards,
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>

[Jacopo Cappellato-4]

Yes, this is fine and I was thinking about a similar solution; however I would like to find a simpler convention because [script:groovy] is a lot of typing and could be difficult to read when the code in buried in the "value" attribute of a "set" element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the "default" language set in some properties file (i.e. "groovy"); this follows the "configuration by exception" pattern (specify the script only if you want to use a non default one).

But we should also consider a shortcut where the "script" word is abbreviated, for example by the "s" word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}

Jacopo

On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:

> I was thinking we could use something like ${[script:groovy]...} ${[script:jython]...} etc. I'm concerned that looking for a string followed by a colon can lead to errors.
>
> -Adrian
>
> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent on ScriptUtil class.
>> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no spaces) followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on existing scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify them to be compatible with the convention. I intentionally didn't focus on this second step.
>>
>> Jacopo
>>
>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>
>>> I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
>>> So I thought at some point you have to check which language wich is used?
>>>
>>> Like in
>>> +        if ("groovy".equals(language)) {
>>> +            if (scriptClass == null) {
>>> +                scriptClass = ScriptUtil.parseScript(language, script);
>>> +            }
>>> +            if (scriptClass != null) {
>>> +                result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
>>> +            }
>>> +        } else if ("bsh".equals(language)) {
>>> +            result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
>>> +        }
>>>
>>> In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?
>>>
>>> Jacques
>>>
>>> From: "Adrian Crum"<[hidden email]>
>>>> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting engine
>>>> is supplied with OFBiz.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but
>>>>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean
>>>>> it's the idea and what Jacopo said already.
>>>>>
>>>>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB
>>>>> seems to be common sense. We chose groovy...
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>> The code changes tested fine.
>>>>>>
>>>>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think
>>>>>> that?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>> My changes are in commit 1296762
>>>>>>>
>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>
>>>>>>>> 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.
>>>>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>>>>> I will commit my code changes today.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>
>>>>>>>>

[Adrian Crum-3]

Okay, we can give it a try and see if we run into any problems.

Btw, expressions should go in the from-field attribute, not the value
attribute.

-Adrian

On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:

> Yes, this is fine and I was thinking about a similar solution; however I would like to find a simpler convention because [script:groovy] is a lot of typing and could be difficult to read when the code in buried in the "value" attribute of a "set" element.
> Something like:
> ${script:jython code_here}
> ${script:groovy code_here}
> ${script: code_here} this could use the "default" language set in some properties file (i.e. "groovy"); this follows the "configuration by exception" pattern (specify the script only if you want to use a non default one).
>
> But we should also consider a shortcut where the "script" word is abbreviated, for example by the "s" word:
> ${s:jython code_here}
> ${s:groovy code_here}
> ${s: code_here}
>
> Jacopo
>
> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>
>> I was thinking we could use something like ${[script:groovy]...} ${[script:jython]...} etc. I'm concerned that looking for a string followed by a colon can lead to errors.
>>
>> -Adrian
>>
>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent on ScriptUtil class.
>>> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no spaces) followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on existing scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify them to be compatible with the convention. I intentionally didn't focus on this second step.
>>>
>>> Jacopo
>>>
>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>
>>>> I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
>>>> So I thought at some point you have to check which language wich is used?
>>>>
>>>> Like in
>>>> +        if ("groovy".equals(language)) {
>>>> +            if (scriptClass == null) {
>>>> +                scriptClass = ScriptUtil.parseScript(language, script);
>>>> +            }
>>>> +            if (scriptClass != null) {
>>>> +                result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
>>>> +            }
>>>> +        } else if ("bsh".equals(language)) {
>>>> +            result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
>>>> +        }
>>>>
>>>> In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?
>>>>
>>>> Jacques
>>>>
>>>> From: "Adrian Crum"<[hidden email]>
>>>>> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting engine
>>>>> is supplied with OFBiz.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>>>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but
>>>>>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean
>>>>>> it's the idea and what Jacopo said already.
>>>>>>
>>>>>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB
>>>>>> seems to be common sense. We chose groovy...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>> The code changes tested fine.
>>>>>>>
>>>>>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think
>>>>>>> that?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>>> My changes are in commit 1296762
>>>>>>>>
>>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>>>>>> I will commit my code changes today.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

[Jacopo Cappellato-4]

On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:

> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.

Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.

>
> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>

I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.

Jacopo

> -Adrian
>
> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>
>>> The code changes tested fine.
>>>
>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think that?
>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>
>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>
>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>
>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>
>> Jacopo
>>
>>> -Adrian
>>>
>>>
>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>> My changes are in commit 1296762
>>>>
>>>> Help with reviews and tests will be very much appreciated.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>
>>>>> 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.
>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>> I will commit my code changes today.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>

[Jacopo Cappellato-4]

On Mar 5, 2012, at 8:57 AM, Adrian Crum wrote:

> Btw, expressions should go in the from-field attribute, not the value attribute.

Well, the mechanism value="${groovy: ...}" is actually used a lot currently; and in the from-field attribute the ${groovy: is not required.

Jacopo