Definitively remove beanshell from OFBiz

[Erwan de FERRIERES <er...@gmail.com>]

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

Re: Definitively remove beanshell from OFBiz

[Erwan de FERRIERES <er...@gmail.com>]

2012/2/8 Pierre Smits <pi...@gmail.com>:
> 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

Re: Definitively remove beanshell from OFBiz

[Pierre Smits <pi...@gmail.com>]

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 <er...@gmail.com>

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

Re: Definitively remove beanshell from OFBiz

[Erwan de FERRIERES <er...@gmail.com>]

2012/2/12 Adrian Crum <ad...@sandglass-software.com>:
> 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

Re: Framework refactor

[Hans Bakker <ma...@antwebsystems.com>]

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

Re: Framework refactor

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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
> 

Re: Framework refactor

[Hans Bakker <ma...@antwebsystems.com>]

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

Re: Framework refactor

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Framework refactor

[Bruno Busco <br...@gmail.com>]

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 <ja...@hotwaxmedia.com>

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

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones <de...@me.com>]

NOTE: replying to this in multiple messages for better digestibility. :)

Jacopo Cappellato wrote:
> Thank you David,
> 
> please see inline:
> 
> On Mar 15, 2012, at 6:08 AM, David E Jones wrote:
> 
>> I think the Moqui Framework is already to a point where migration
>> of OFBiz business-level artifacts could begin immediately.
> 
> Of course I would be happy to see (and help with) an effort to create
> a relatively complex proof of concepts for the migration. Then we
> will have a better ground to evaluate pros and cons of the two
> frameworks.

There is an example application in Moqui that is similar to the one in
OFBiz, though focusing on the main screens and not including all of the
JS and other feature demo screens.

The online demo (running on Amazon Elastic Beanstalk) is here:

http://demo.moqui.org/apps/example/Example

The source code can be viewed through GitHub here:

https://github.com/jonesde/moqui/tree/master/runtime/component/example

-David

Re: Framework refactor (Moqui-/Mantle-specific)

[Adrian Crum <ad...@sandglass-software.com>]

The mini-lang overhaul only effects the grammar, not the performance. No 
one can comment on the framework performance until a decision is made 
about the direction it will take.

-Adrian

On 3/16/2012 8:09 AM, Pierre Smits wrote:
> Hi all,
>
> Currently there are several threads regarding the overhaul of the
> framework, the mini-lang, and other structures. But how will all these
> affect the performance?
>
> I haven't seen anything on that subject.
>
> Regards,
>
> Pierre
>
> Op 16 maart 2012 02:15 schreef David E Jones<de...@me.com>  het volgende:
>
>>
>> Jacopo Cappellato wrote:
>>>> 3. running in a single webapp: while this isn't necessary with
>>>> Moqui, the Moqui Screens are a combination of the controller.xml
>>>> entries for the particular screen and the OFBiz Screen Widget, and
>>>> are hierarchical instead of being flat like the request-map URIs in
>>>> OFBiz; this allows apps to plug into a screen hierarchy from
>>>> separate places (by explicit inclusion, a database record, or
>>>> implicitly by directory structure)
>>> The existing OFBiz screen/form widget is an area where OFBiz should
>>> be greatly improved in my opinion. Some of the things I don't like: *
>>> the "configuration by exception" patter should be used more
>>> extensively (most common screen definitions, controller entries
>>> etc... should not be required) * it is difficult to build complex
>>> Ajax screens * I don't like the xml code for screen/form actions: it
>>> is limited and it is an additional programming language to learn * in
>>> simpler screen it is an overkill to maintain in separate files the
>>> data preparation script, the form definition and the screen
>>> definition * the html code that is produced by the widgets is ugly
>>> and difficult to maintain
>>>
>>> It seems that some of the points above have been addressed by Moqui;
>>> David, did you ever consider to integrate other ui frameworks in
>>> Moqui? I know that in Moqui there is a more powerful mechanism to
>>> automatically render ui elements (e.g. submenu items for subscreens
>>> etc...) but frankly speaking I am less interested in them because I
>>> have learned that these tools are great to cover the 80% of the
>>> requirements of a ui but the work on the remaining 20% still has to
>>> be done in each and every screen to make it really usable. But I
>>> would be really interested to see a rather complex Moqui screen that
>>> uses Ajax and calls events: this would help me to evaluate the
>>> advantages of the new solution.
>> I don't know of any magic formulas for web-based UI stuff. Even a lot of
>> the desktop UI stuff is quite a pain and only elaborate visual-design
>> tools make it easier... and when those aren't adequate for what you want
>> to build life gets hard in a hurry.
>>
>> One thing that the Moqui screens have that help with this is that it is
>> easier to extend the form and screen definitions by just adding macros
>> to an FTL template that extends and/or overrides the default templates.
>> You can add your new tags to an XSD file if you want so that things will
>> validate properly in your IDE, but that is not necessary for the new
>> tags to function.
>>
>> This still isn't a silver bullet, but at least it makes it easier to
>> incorporate consistent UI widgets based on jQuery plugins or your own
>> hand-rolled stuff or whatever so that it is not necessary to have HTML
>> and/or JavaScript snippets to use each of these on each screen/page that
>> needs them.
>>
>> It is also easier to inline HTML and JavaScript in a screen definition,
>> so that doesn't have to be maintained in a separate file... and have
>> have HTML inline in a form field and such. In other words, you can drop
>> it just about anywhere, making it much easier to do crazy stuff with the
>> screen and form XML files so you don't have to drop to FTL templates so
>> often.
>>
>> OOTB the Moqui XML Screens and XML Forms use more JavaScript and dynamic
>> stuff than the OFBiz ones, but there is still a LOT of room for
>> improvement and it is something I'd like to do more of, or work with
>> other who do it to get it into the project (any takers? :) ).
>>
>> If you have other ideas about what an artifact might look like that
>> would be easier for UI stuff, I would be very interested in discussing
>> it more. You have a lot of good ideas Jacopo, and I appreciate them a
>> great deal.
>>
>> -David
>>
>>

Re: Framework refactor (Moqui-/Mantle-specific)

[Pierre Smits <pi...@gmail.com>]

Hi all,

Currently there are several threads regarding the overhaul of the
framework, the mini-lang, and other structures. But how will all these
affect the performance?

I haven't seen anything on that subject.

Regards,

Pierre

Op 16 maart 2012 02:15 schreef David E Jones <de...@me.com> het volgende:

>
>
> Jacopo Cappellato wrote:
> >> 3. running in a single webapp: while this isn't necessary with
> >> Moqui, the Moqui Screens are a combination of the controller.xml
> >> entries for the particular screen and the OFBiz Screen Widget, and
> >> are hierarchical instead of being flat like the request-map URIs in
> >> OFBiz; this allows apps to plug into a screen hierarchy from
> >> separate places (by explicit inclusion, a database record, or
> >> implicitly by directory structure)
> >
> > The existing OFBiz screen/form widget is an area where OFBiz should
> > be greatly improved in my opinion. Some of the things I don't like: *
> > the "configuration by exception" patter should be used more
> > extensively (most common screen definitions, controller entries
> > etc... should not be required) * it is difficult to build complex
> > Ajax screens * I don't like the xml code for screen/form actions: it
> > is limited and it is an additional programming language to learn * in
> > simpler screen it is an overkill to maintain in separate files the
> > data preparation script, the form definition and the screen
> > definition * the html code that is produced by the widgets is ugly
> > and difficult to maintain
> >
> > It seems that some of the points above have been addressed by Moqui;
> > David, did you ever consider to integrate other ui frameworks in
> > Moqui? I know that in Moqui there is a more powerful mechanism to
> > automatically render ui elements (e.g. submenu items for subscreens
> > etc...) but frankly speaking I am less interested in them because I
> > have learned that these tools are great to cover the 80% of the
> > requirements of a ui but the work on the remaining 20% still has to
> > be done in each and every screen to make it really usable. But I
> > would be really interested to see a rather complex Moqui screen that
> > uses Ajax and calls events: this would help me to evaluate the
> > advantages of the new solution.
>
> I don't know of any magic formulas for web-based UI stuff. Even a lot of
> the desktop UI stuff is quite a pain and only elaborate visual-design
> tools make it easier... and when those aren't adequate for what you want
> to build life gets hard in a hurry.
>
> One thing that the Moqui screens have that help with this is that it is
> easier to extend the form and screen definitions by just adding macros
> to an FTL template that extends and/or overrides the default templates.
> You can add your new tags to an XSD file if you want so that things will
> validate properly in your IDE, but that is not necessary for the new
> tags to function.
>
> This still isn't a silver bullet, but at least it makes it easier to
> incorporate consistent UI widgets based on jQuery plugins or your own
> hand-rolled stuff or whatever so that it is not necessary to have HTML
> and/or JavaScript snippets to use each of these on each screen/page that
> needs them.
>
> It is also easier to inline HTML and JavaScript in a screen definition,
> so that doesn't have to be maintained in a separate file... and have
> have HTML inline in a form field and such. In other words, you can drop
> it just about anywhere, making it much easier to do crazy stuff with the
> screen and form XML files so you don't have to drop to FTL templates so
> often.
>
> OOTB the Moqui XML Screens and XML Forms use more JavaScript and dynamic
> stuff than the OFBiz ones, but there is still a LOT of room for
> improvement and it is something I'd like to do more of, or work with
> other who do it to get it into the project (any takers? :) ).
>
> If you have other ideas about what an artifact might look like that
> would be easier for UI stuff, I would be very interested in discussing
> it more. You have a lot of good ideas Jacopo, and I appreciate them a
> great deal.
>
> -David
>
>

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones <de...@me.com>]

Jacopo Cappellato wrote:
>> 3. running in a single webapp: while this isn't necessary with
>> Moqui, the Moqui Screens are a combination of the controller.xml
>> entries for the particular screen and the OFBiz Screen Widget, and
>> are hierarchical instead of being flat like the request-map URIs in
>> OFBiz; this allows apps to plug into a screen hierarchy from
>> separate places (by explicit inclusion, a database record, or
>> implicitly by directory structure)
> 
> The existing OFBiz screen/form widget is an area where OFBiz should
> be greatly improved in my opinion. Some of the things I don't like: *
> the "configuration by exception" patter should be used more
> extensively (most common screen definitions, controller entries
> etc... should not be required) * it is difficult to build complex
> Ajax screens * I don't like the xml code for screen/form actions: it
> is limited and it is an additional programming language to learn * in
> simpler screen it is an overkill to maintain in separate files the
> data preparation script, the form definition and the screen
> definition * the html code that is produced by the widgets is ugly
> and difficult to maintain
> 
> It seems that some of the points above have been addressed by Moqui;
> David, did you ever consider to integrate other ui frameworks in
> Moqui? I know that in Moqui there is a more powerful mechanism to
> automatically render ui elements (e.g. submenu items for subscreens
> etc...) but frankly speaking I am less interested in them because I
> have learned that these tools are great to cover the 80% of the
> requirements of a ui but the work on the remaining 20% still has to
> be done in each and every screen to make it really usable. But I
> would be really interested to see a rather complex Moqui screen that
> uses Ajax and calls events: this would help me to evaluate the
> advantages of the new solution.

I don't know of any magic formulas for web-based UI stuff. Even a lot of
the desktop UI stuff is quite a pain and only elaborate visual-design
tools make it easier... and when those aren't adequate for what you want
to build life gets hard in a hurry.

One thing that the Moqui screens have that help with this is that it is
easier to extend the form and screen definitions by just adding macros
to an FTL template that extends and/or overrides the default templates.
You can add your new tags to an XSD file if you want so that things will
validate properly in your IDE, but that is not necessary for the new
tags to function.

This still isn't a silver bullet, but at least it makes it easier to
incorporate consistent UI widgets based on jQuery plugins or your own
hand-rolled stuff or whatever so that it is not necessary to have HTML
and/or JavaScript snippets to use each of these on each screen/page that
needs them.

It is also easier to inline HTML and JavaScript in a screen definition,
so that doesn't have to be maintained in a separate file... and have
have HTML inline in a form field and such. In other words, you can drop
it just about anywhere, making it much easier to do crazy stuff with the
screen and form XML files so you don't have to drop to FTL templates so
often.

OOTB the Moqui XML Screens and XML Forms use more JavaScript and dynamic
stuff than the OFBiz ones, but there is still a LOT of room for
improvement and it is something I'd like to do more of, or work with
other who do it to get it into the project (any takers? :) ).

If you have other ideas about what an artifact might look like that
would be easier for UI stuff, I would be very interested in discussing
it more. You have a lot of good ideas Jacopo, and I appreciate them a
great deal.

-David

Re: Framework refactor (Moqui-/Mantle-specific)

[Adrian Crum <ad...@sandglass-software.com>]

On 3/15/2012 9:20 AM, Jacopo Cappellato wrote:
> On Mar 15, 2012, at 9:46 AM, Jacopo Cappellato wrote:
>
>> Adrian, it was a joke not real criticism on you.
> And to be very clear: I appreciate all the work you did to add support to JSR-223

We're cool. ;-)

-Adrian

Re: Framework refactor (Moqui-/Mantle-specific)

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Mar 15, 2012, at 9:46 AM, Jacopo Cappellato wrote:

> Adrian, it was a joke not real criticism on you.

And to be very clear: I appreciate all the work you did to add support to JSR-223

Jacopo

Re: Framework refactor (Moqui-/Mantle-specific)

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Mar 15, 2012, at 9:38 AM, Adrian Crum wrote:

> On 3/15/2012 7:57 AM, Jacopo Cappellato wrote:
>> Not only this; well, yes it is simply this at the technical level but it is much much more in the end result and approach: in fact in my poc I have laid out some simple but very effective best practices for programming services and events: the code I added is minimal (a few lines... that after Adrian's refactoring became 10 times more... but the OFBiz community likes heavy stuff :-) )
> 
> The refactoring might have added a few lines to the Groovy implementation, but it also eliminates the need for these classes:
> 
> BshUtil.java
> GroovyUtil.java
> BeanShellEngine.java
> BSFEngine.java
> GroovyEngine.java
> BsfEventHandler.java
> GroovyEventHandler.java
> 
> and when mini-language implements JSR-223, these classes will not be needed:
> 
> SimpleEventHandler.java
> SimpleServiceEngine.java
> 
> The refactoring also adds support for many more scripting languages.
> 
> So, I'm having a hard time understanding how the elimination of nine classes (1100 lines of code) while adding support for more scripting languages can be considered "heavy stuff."

Adrian, it was a joke not real criticism on you.
However I was not talking about the JSR-223 work in general but about the conversion of the specific DSL language class into the helper/factory pattern; that added a lot of code to a poc class that was intended to enhance Groovy for OFBiz. But you are right, in *theory* 100 different languages could use the new helper classes now and at that point the overhead would make a lot of sense: but we will never really know if they will be used out of OFBiz.

Jacopo

> 
> -Adrian
> 

Re: Framework refactor (Moqui-/Mantle-specific)

[Adrian Crum <ad...@sandglass-software.com>]

On 3/15/2012 7:57 AM, Jacopo Cappellato wrote:
> Not only this; well, yes it is simply this at the technical level but 
> it is much much more in the end result and approach: in fact in my poc 
> I have laid out some simple but very effective best practices for 
> programming services and events: the code I added is minimal (a few 
> lines... that after Adrian's refactoring became 10 times more... but 
> the OFBiz community likes heavy stuff :-) )

The refactoring might have added a few lines to the Groovy 
implementation, but it also eliminates the need for these classes:

BshUtil.java
GroovyUtil.java
BeanShellEngine.java
BSFEngine.java
GroovyEngine.java
BsfEventHandler.java
GroovyEventHandler.java

and when mini-language implements JSR-223, these classes will not be needed:

SimpleEventHandler.java
SimpleServiceEngine.java

The refactoring also adds support for many more scripting languages.

So, I'm having a hard time understanding how the elimination of nine 
classes (1100 lines of code) while adding support for more scripting 
languages can be considered "heavy stuff."

-Adrian

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones <de...@me.com>]

Jacopo Cappellato wrote:
>> Doing a migration like this would bring up other issues...
>> including whether or not to clean up the data model and services
>> while at it, especially rewriting messier parts of OFBiz like the
>> ShoppingCart* objects and order processing stuff in general.
>> 
> 
> It will be very difficult to rewrite existing stuff, and doing this
> before or after the migration wouldn't change its complexity. For
> this reason I think we can keep this topic out of this thread for
> now. However, instead of rewriting, we could clean up what we have in
> OFBiz before the migration... especially if this could simplify the
> migration or make the existing code better organized. For example, in
> another thread I was proposing to merge the existing application
> components into one, with possibly one webapp and less (and more
> consolidated) files: this may seem a huge effort but it may not be,
> because it could be done in baby steps with a lot of string
> replacements, moving/renaming files around etc... we could even
> create some scripts to simplify the effort. But again, also this
> could be done before/after the migration (or never).

Some of it could certainly be improved with a rewrite, or perhaps more
of a serious refactor. For example, using the database for shopping cart
data instead of an object in the session would be far more flexible for
a variety of order processing apps, especially outside of the normal
ecommerce submit-all-at-once flow.

But yes, this introduces another whole big set of issues and
discussions. Actually, frankly I'm surprised there is consideration of
any major framework changes, let alone moving to a new framework,
because so much effort is required to update or migrate all of the
existing business artifacts. That has killed a lot of framework
enhancement efforts over the years.

The main trick I'd see with combining webapps in the current
ofbiz/applications components is the request-map uri and view-map name
namespaces, ie the issue with duplicate names pointing to different
events and screens and such.

In Moqui these controller files would go away and the request-map and
view-map data goes into the screen definitions, but I can't think of any
changes that could be made now and supported by OFBiz to help move
toward this.

>> If you want to stick with everything as-is and just do a migration,
>> that should actually be much less work than you might think. I have
>> some FTL templates to transform entity and service definitions, and
>> a partial template for simple-methods. Similar templates could be
>> made for screens and forms, though they are more complicated and
>> may require more manual work. Things like groovy scripts and Java
>> classes will also require a bit more work, but many patterns are
>> similar so it would be much less work than moving to an
>> object-relational sort of framework (ie Hibernate/JPA type of
>> thing).
>
> This doesn't help much to make me comfortable :-) David, it may help
> if you could list a series of tasks (if any) we could perform in one
> of the OFBiz application components to make it more ready to be
> migrated: the tasks should ideally be doable in steps, and after each
> step the component should be usable in the existing OFBiz framework;
> but the code should be more compliant with the future layout of Moqui
> (or with what the migration scripts will expect); for example we
> could: * merge/split service, entity, screen/forms definitions in
> one/more files * merge Groovy scripts into one file with several
> methods (one per data preparation script) * merge/split Java classes
> for services * merge/split xml files with services * etc. etc..

As for what can be done in advance to prepare for it, I don't think that
splitting or combining files is too big a deal because that can be done
by a tool more easily than by a human.

The main area where Moqui differs from OFBiz Framework in terms of
artifacts per file is the screens. In Moqui there is one screen per file
as opposed to multiple screens per file, and they are hierarchical as
opposed to flat (or more of a network for decoration/inclusion/etc).
This could be done manually, but it could also be done by a tool and
perhaps more easily.

-David

Re: Framework refactor (Moqui-/Mantle-specific)

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Thank you David,

please see inline:

On Mar 15, 2012, at 6:08 AM, David E Jones wrote:

> 
> I think the Moqui Framework is already to a point where migration of
> OFBiz business-level artifacts could begin immediately.

Of course I would be happy to see (and help with) an effort to create a relatively complex proof of concepts for the migration. Then we will have a better ground to evaluate pros and cons of the two frameworks.

> 
> Doing a migration like this would bring up other issues... including
> whether or not to clean up the data model and services while at it,
> especially rewriting messier parts of OFBiz like the ShoppingCart*
> objects and order processing stuff in general.
> 

It will be very difficult to rewrite existing stuff, and doing this before or after the migration wouldn't change its complexity.
For this reason I think we can keep this topic out of this thread for now.
However, instead of rewriting, we could clean up what we have in OFBiz before the migration... especially if this could simplify the migration or make the existing code better organized.
For example, in another thread I was proposing to merge the existing application components into one, with possibly one webapp and less (and more consolidated) files: this may seem a huge effort but it may not be, because it could be done in baby steps with a lot of string replacements, moving/renaming files around etc... we could even create some scripts to simplify the effort.
But again, also this could be done before/after the migration (or never).

> If you want to stick with everything as-is and just do a migration, that
> should actually be much less work than you might think. I have some FTL
> templates to transform entity and service definitions, and a partial
> template for simple-methods. Similar templates could be made for screens
> and forms, though they are more complicated and may require more manual
> work. Things like groovy scripts and Java classes will also require a
> bit more work, but many patterns are similar so it would be much less
> work than moving to an object-relational sort of framework (ie
> Hibernate/JPA type of thing).

This doesn't help much to make me comfortable :-)
David, it may help if you could list a series of tasks (if any) we could perform in one of the OFBiz application components to make it more ready to be migrated: the tasks should ideally be doable in steps, and after each step the component should be usable in the existing OFBiz framework; but the code should be more compliant with the future layout of Moqui (or with what the migration scripts will expect); for example we could:
* merge/split service, entity, screen/forms definitions in one/more files
* merge Groovy scripts into one file with several methods (one per data preparation script)
* merge/split Java classes for services
* merge/split xml files with services
* etc. etc..

> 
> While on the topic, some notes about things I saw in some related threads:
> 
> 1. the DSL/Helper class effort is in principle just an improved API for
> framework tools;

Not only this; well, yes it is simply this at the technical level but it is much much more in the end result and approach: in fact in my poc I have laid out some simple but very effective best practices for programming services and events: the code I added is minimal (a few lines... that after Adrian's refactoring became 10 times more... but the OFBiz community likes heavy stuff :-) ) and in fact the building blocks of my work have been there since we introduced Groovy for scripts (to replace Beanshell); but since then no one really did this small step to enable Groovy (with a series of best practices and a small set of methods) to be used in a way that is perfect for OFBiz (and it was the reason that made Minilang such a productive tool).
I really think that the 50 lines of code I wrote, together with the best practices defined by the two examples I have provided (for error/event/message handling) would represent a huge step ahead if used extensively to create new code (or to convert old one).
But of course the same concepts can be easily applied to Moqui.

> the OFBiz framework tools were originally implemented
> independently, and based on a LOT of static methods and static
> initialization, resulting in an "API" that is made up of a bunch of
> independent objects that I've found are opaque even to developers with
> years of OFBiz experience (ie they are not aware of functionality
> because it is so hard to find); the Moqui API takes care of this problem
> with an API designed to actually be an API as opposed to a bunch of
> independent classes that evolved; for more info on that, see:
> 
> http://www.moqui.org/apiJavadoc/index.html
> 
> ... and the central object of the API (that also has contextual details
> for the current request/user/etc):
> 
> http://www.moqui.org/apiJavadoc/org/moqui/context/ExecutionContext.html
> 
> Here are some quick examples of how this looks in actual use (from the
> sendEmailTemplate.groovy script; sorry for the wrapping):
> 
> def emailTemplate =
> ec.entity.makeFind("moqui.basic.email.EmailTemplate").condition("emailTemplateId",
> emailTemplateId).one()
> 
> String bodyText =
> ec.screen.makeRender().rootScreen(emailTemplate.bodyScreenLocation).renderMode("text").render()
> 
> Map cemParms = [sentDate:ec.user.nowTimestamp, subject:subject,
> body:bodyHtml, fromAddress:emailTemplate.fromAddress,
> toAddresses:toAddresses, ccAddresses:emailTemplate.ccAddresses,
> bccAddresses:emailTemplate.bccAddresses, contentType:"text/html",
> emailTemplateId:emailTemplateId,fromUserId:ec.user.userId]
> ec.service.sync().name("create",
> "moqui.basic.email.EmailMessage").parameters(cemParms).call()
> 

The Moqui API is of course cleaner because it was implemented from scratch based on lesson learned so far in OFBiz, and this is a *great* reason for me to consider the migration to Moqui (another one is that you are the architect of Moqui).
However I would be really interested to see a service implementation in Moqui of one of the Java/Minilang services we have in OFBiz, like the poc I did to demonstrate my work on Groovy+DSL.

> 2. consolidating OFBiz data model and services into a single component:
> this is the way the Mantle UDM and USL are currently organized, though
> they are restricted to very generic stuff and application-specific
> extensions would live in the corresponding application
> 
> 3. running in a single webapp: while this isn't necessary with Moqui,
> the Moqui Screens are a combination of the controller.xml entries for
> the particular screen and the OFBiz Screen Widget, and are hierarchical
> instead of being flat like the request-map URIs in OFBiz; this allows
> apps to plug into a screen hierarchy from separate places (by explicit
> inclusion, a database record, or implicitly by directory structure)

The existing OFBiz screen/form widget is an area where OFBiz should be greatly improved in my opinion.
Some of the things I don't like:
* the "configuration by exception" patter should be used more extensively (most common screen definitions, controller entries etc... should not be required)
* it is difficult to build complex Ajax screens
* I don't like the xml code for screen/form actions: it is limited and it is an additional programming language to learn
* in simpler screen it is an overkill to maintain in separate files the data preparation script, the form definition and the screen definition
* the html code that is produced by the widgets is ugly and difficult to maintain

It seems that some of the points above have been addressed by Moqui; David, did you ever consider to integrate other ui frameworks in Moqui?
I know that in Moqui there is a more powerful mechanism to automatically render ui elements (e.g. submenu items for subscreens etc...) but frankly speaking I am less interested in them because I have learned that these tools are great to cover the 80% of the requirements of a ui but the work on the remaining 20% still has to be done in each and every screen to make it really usable.
But I would be really interested to see a rather complex Moqui screen that uses Ajax and calls events: this would help me to evaluate the advantages of the new solution.

Kind regards,

Jacopo

> 
> ================================
> 
> This might actually be good in a separate email, but anyway...
> 
> The Moqui Framework would be a separate project from OFBiz, and while
> some OFBiz committers could certainly become moderators for Moqui that
> would be based on their personal efforts and merits and not anything to
> do with what happens or has happened in OFBiz.
> 
> Moqui has a lot more extension points built-in than the OFBiz Framework,
> so you can actually do quite a bit without changing the framework
> itself. For cases where changes are needed (or wanted) to Moqui itself
> they would go through the normal feature request and patch submission
> process for Moqui to be reviewed by a moderator. Initially this would be
> me, and I obviously have some skin invested in an effort like this so
> I'd try to be responsive as possible (I have been so far with Moqui, but
> most of the time it has had light traffic so I've been able to get
> things reviewed and changed/fixed within a couple of days).
> 
> One of the easiest ways to do that is with a pull request on GitHub. In
> fact, if the OFBiz variation of the Moqui Framework was managed on
> GitHub you could customize things there as desired while still being
> able to submit changes back to Moqui and get updates from Moqui so that
> OFBiz can more easily participate in the Moqui community. In git
> terminology this would actually be a "fork", and I think is what Jacopo
> was talking about.
> 
> Still, for the most part my guess is that this would not be needed and
> I'd recommend starting with just the jar files (or even just the war
> file) and not set things up for easily changing the framework until the
> need for doing so is well established.
> 
> For this interested in considering Moqui for use in OFBiz, the tutorial
> and framework intro docs are probably the best places to start, and the
> Run/Deploy doc is also helpful (BTW, the moqui.org site is actually
> running on Moqui, and the tutorial and run/deploy docs are actually
> cwiki documents (confluence-style wiki text)):
> 
> http://www.moqui.org/framework/docs/Tutorial.html
> 
> http://sourceforge.net/projects/moqui/files/IntroductionToMoquiFramework-1.0.1.pdf/download
> 
> http://www.moqui.org/framework/docs/RunDeploy.html
> 
> Anyway, sorry for the delay in responding to this. I'm still a bit busy
> on contracts and I only catch up on the OFBiz mailing lists every week
> or so.
> 
> -David
> 
> 
> 
> 
> Jacopo Cappellato wrote:
>> 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)

Re: Framework refactor

["shi.jinghai" <hu...@hotmail.com>]

+1 to 3.a).


On 2012-3-2, at 下午4:28, Jacopo Cappellato wrote:

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

Re: Framework refactor

[Nicolas Malin <ma...@librenberry.net>]

Hi Jacopo,

Interesting discussion :)

Like you said, the selected solution will have all the features we need. 
At this time Apache OFBiz offering a great functional framework with 
technical interface, this allows to functional developer to stay focused 
on their needsand don't waste on technical problem. It's really 
important to don't lose it.

My feedback between Neogia and OFBiz (since we have in the same case 
that choice 3) and 4))

  * Fork : easier to improve the framework, but really difficult to back 
improvements to original project. Many waste time to realize 
improvement in parallel. I don't recommend it
  * Synchronize by repository : import a external framework release, 
provides flexibility to update the external source and show own 
improvement. But with time past, the differences grow, increasing the 
synchro time and decreasing the back improvement quality. We stop this 
solution there are two years.
   * At this time, with develop addon manager system to separate each 
improvement on dedicate addon. This simplify the synchronization with 
external source, keep back improvement quality. We lost in commit 
celerit, it's a little more complicated to improve an addon than only 
commit in a repository.

Whatever solution, I am available to help you.

Nicolas

Le 02/03/2012 09:28, Jacopo Cappellato a écrit :
> 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)


-- 
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones <de...@me.com>]

The only library that is not friendly right now is the Redstone XMLRPC
library, which is LGPL licensed. That could be replaced by the Apache
XML-RPC project. The only reasons I used Redstone are that it is much
smaller (library bloat is a real problem), and it is a bit easier to use.

There are a couple of libraries that use CDDL (winstone servlet
container) and EPL (Mylin WikiText), but they are in binary form only so
should be fine.

If there is enough interest I'd be happy to change Moqui to use Apache
XML-RPC instead of Redstone.

-David


Jacopo Cappellato wrote:
> David,
> 
> a side note (but important): is Moqui using (or there are plans to use) jars or external tools whose license would prevent us from bundling Moqui in an OFBiz release under the ASL 2.0? This would be a show stopper...
> 
> Jacopo
> 
> On Mar 15, 2012, at 6:08 AM, David E Jones wrote:
> 
>> This might actually be good in a separate email, but anyway...
>>
>> The Moqui Framework would be a separate project from OFBiz, and while
>> some OFBiz committers could certainly become moderators for Moqui that
>> would be based on their personal efforts and merits and not anything to
>> do with what happens or has happened in OFBiz.
>>
>> Moqui has a lot more extension points built-in than the OFBiz Framework,
>> so you can actually do quite a bit without changing the framework
>> itself. For cases where changes are needed (or wanted) to Moqui itself
>> they would go through the normal feature request and patch submission
>> process for Moqui to be reviewed by a moderator. Initially this would be
>> me, and I obviously have some skin invested in an effort like this so
>> I'd try to be responsive as possible (I have been so far with Moqui, but
>> most of the time it has had light traffic so I've been able to get
>> things reviewed and changed/fixed within a couple of days).
>>
>> One of the easiest ways to do that is with a pull request on GitHub. In
>> fact, if the OFBiz variation of the Moqui Framework was managed on
>> GitHub you could customize things there as desired while still being
>> able to submit changes back to Moqui and get updates from Moqui so that
>> OFBiz can more easily participate in the Moqui community. In git
>> terminology this would actually be a "fork", and I think is what Jacopo
>> was talking about.
>>
>> Still, for the most part my guess is that this would not be needed and
>> I'd recommend starting with just the jar files (or even just the war
>> file) and not set things up for easily changing the framework until the
>> need for doing so is well established.
>>
>> For this interested in considering Moqui for use in OFBiz, the tutorial
>> and framework intro docs are probably the best places to start, and the
>> Run/Deploy doc is also helpful (BTW, the moqui.org site is actually
>> running on Moqui, and the tutorial and run/deploy docs are actually
>> cwiki documents (confluence-style wiki text)):
>>
>> http://www.moqui.org/framework/docs/Tutorial.html
>>
>> http://sourceforge.net/projects/moqui/files/IntroductionToMoquiFramework-1.0.1.pdf/download
>>
>> http://www.moqui.org/framework/docs/RunDeploy.html
>>
>> Anyway, sorry for the delay in responding to this. I'm still a bit busy
>> on contracts and I only catch up on the OFBiz mailing lists every week
>> or so.
>>
>> -David
> 

Re: Framework refactor (Moqui-/Mantle-specific)

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

David,

a side note (but important): is Moqui using (or there are plans to use) jars or external tools whose license would prevent us from bundling Moqui in an OFBiz release under the ASL 2.0? This would be a show stopper...

Jacopo

On Mar 15, 2012, at 6:08 AM, David E Jones wrote:

> This might actually be good in a separate email, but anyway...
> 
> The Moqui Framework would be a separate project from OFBiz, and while
> some OFBiz committers could certainly become moderators for Moqui that
> would be based on their personal efforts and merits and not anything to
> do with what happens or has happened in OFBiz.
> 
> Moqui has a lot more extension points built-in than the OFBiz Framework,
> so you can actually do quite a bit without changing the framework
> itself. For cases where changes are needed (or wanted) to Moqui itself
> they would go through the normal feature request and patch submission
> process for Moqui to be reviewed by a moderator. Initially this would be
> me, and I obviously have some skin invested in an effort like this so
> I'd try to be responsive as possible (I have been so far with Moqui, but
> most of the time it has had light traffic so I've been able to get
> things reviewed and changed/fixed within a couple of days).
> 
> One of the easiest ways to do that is with a pull request on GitHub. In
> fact, if the OFBiz variation of the Moqui Framework was managed on
> GitHub you could customize things there as desired while still being
> able to submit changes back to Moqui and get updates from Moqui so that
> OFBiz can more easily participate in the Moqui community. In git
> terminology this would actually be a "fork", and I think is what Jacopo
> was talking about.
> 
> Still, for the most part my guess is that this would not be needed and
> I'd recommend starting with just the jar files (or even just the war
> file) and not set things up for easily changing the framework until the
> need for doing so is well established.
> 
> For this interested in considering Moqui for use in OFBiz, the tutorial
> and framework intro docs are probably the best places to start, and the
> Run/Deploy doc is also helpful (BTW, the moqui.org site is actually
> running on Moqui, and the tutorial and run/deploy docs are actually
> cwiki documents (confluence-style wiki text)):
> 
> http://www.moqui.org/framework/docs/Tutorial.html
> 
> http://sourceforge.net/projects/moqui/files/IntroductionToMoquiFramework-1.0.1.pdf/download
> 
> http://www.moqui.org/framework/docs/RunDeploy.html
> 
> Anyway, sorry for the delay in responding to this. I'm still a bit busy
> on contracts and I only catch up on the OFBiz mailing lists every week
> or so.
> 
> -David

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones <de...@me.com>]

I think the Moqui Framework is already to a point where migration of
OFBiz business-level artifacts could begin immediately.

Doing a migration like this would bring up other issues... including
whether or not to clean up the data model and services while at it,
especially rewriting messier parts of OFBiz like the ShoppingCart*
objects and order processing stuff in general.

If you want to stick with everything as-is and just do a migration, that
should actually be much less work than you might think. I have some FTL
templates to transform entity and service definitions, and a partial
template for simple-methods. Similar templates could be made for screens
and forms, though they are more complicated and may require more manual
work. Things like groovy scripts and Java classes will also require a
bit more work, but many patterns are similar so it would be much less
work than moving to an object-relational sort of framework (ie
Hibernate/JPA type of thing).

While on the topic, some notes about things I saw in some related threads:

1. the DSL/Helper class effort is in principle just an improved API for
framework tools; the OFBiz framework tools were originally implemented
independently, and based on a LOT of static methods and static
initialization, resulting in an "API" that is made up of a bunch of
independent objects that I've found are opaque even to developers with
years of OFBiz experience (ie they are not aware of functionality
because it is so hard to find); the Moqui API takes care of this problem
with an API designed to actually be an API as opposed to a bunch of
independent classes that evolved; for more info on that, see:

http://www.moqui.org/apiJavadoc/index.html

... and the central object of the API (that also has contextual details
for the current request/user/etc):

http://www.moqui.org/apiJavadoc/org/moqui/context/ExecutionContext.html

Here are some quick examples of how this looks in actual use (from the
sendEmailTemplate.groovy script; sorry for the wrapping):

def emailTemplate =
ec.entity.makeFind("moqui.basic.email.EmailTemplate").condition("emailTemplateId",
emailTemplateId).one()

String bodyText =
ec.screen.makeRender().rootScreen(emailTemplate.bodyScreenLocation).renderMode("text").render()

Map cemParms = [sentDate:ec.user.nowTimestamp, subject:subject,
body:bodyHtml, fromAddress:emailTemplate.fromAddress,
toAddresses:toAddresses, ccAddresses:emailTemplate.ccAddresses,
bccAddresses:emailTemplate.bccAddresses, contentType:"text/html",
emailTemplateId:emailTemplateId,fromUserId:ec.user.userId]
ec.service.sync().name("create",
"moqui.basic.email.EmailMessage").parameters(cemParms).call()

2. consolidating OFBiz data model and services into a single component:
this is the way the Mantle UDM and USL are currently organized, though
they are restricted to very generic stuff and application-specific
extensions would live in the corresponding application

3. running in a single webapp: while this isn't necessary with Moqui,
the Moqui Screens are a combination of the controller.xml entries for
the particular screen and the OFBiz Screen Widget, and are hierarchical
instead of being flat like the request-map URIs in OFBiz; this allows
apps to plug into a screen hierarchy from separate places (by explicit
inclusion, a database record, or implicitly by directory structure)

================================

This might actually be good in a separate email, but anyway...

The Moqui Framework would be a separate project from OFBiz, and while
some OFBiz committers could certainly become moderators for Moqui that
would be based on their personal efforts and merits and not anything to
do with what happens or has happened in OFBiz.

Moqui has a lot more extension points built-in than the OFBiz Framework,
so you can actually do quite a bit without changing the framework
itself. For cases where changes are needed (or wanted) to Moqui itself
they would go through the normal feature request and patch submission
process for Moqui to be reviewed by a moderator. Initially this would be
me, and I obviously have some skin invested in an effort like this so
I'd try to be responsive as possible (I have been so far with Moqui, but
most of the time it has had light traffic so I've been able to get
things reviewed and changed/fixed within a couple of days).

One of the easiest ways to do that is with a pull request on GitHub. In
fact, if the OFBiz variation of the Moqui Framework was managed on
GitHub you could customize things there as desired while still being
able to submit changes back to Moqui and get updates from Moqui so that
OFBiz can more easily participate in the Moqui community. In git
terminology this would actually be a "fork", and I think is what Jacopo
was talking about.

Still, for the most part my guess is that this would not be needed and
I'd recommend starting with just the jar files (or even just the war
file) and not set things up for easily changing the framework until the
need for doing so is well established.

For this interested in considering Moqui for use in OFBiz, the tutorial
and framework intro docs are probably the best places to start, and the
Run/Deploy doc is also helpful (BTW, the moqui.org site is actually
running on Moqui, and the tutorial and run/deploy docs are actually
cwiki documents (confluence-style wiki text)):

http://www.moqui.org/framework/docs/Tutorial.html

http://sourceforge.net/projects/moqui/files/IntroductionToMoquiFramework-1.0.1.pdf/download

http://www.moqui.org/framework/docs/RunDeploy.html

Anyway, sorry for the delay in responding to this. I'm still a bit busy
on contracts and I only catch up on the OFBiz mailing lists every week
or so.

-David




Jacopo Cappellato wrote:
> 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)

Re: Framework refactor

[Adrian Crum <ad...@sandglass-software.com>]

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

Re: Framework refactor

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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)

Re: Framework refactor

[Hans Bakker <ma...@antwebsystems.com>]

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"<ja...@hotwaxmedia.com>
>>>> I don't think it will be easy and actually it may be unfeasible but I see some good reasons for hope:
>>>>
>>>> * the general discussion/vote would involve all committers and not only PMC members: everyone would be involved in the decision
>>>> and in the responsibilities/consequences around it
>>>> * our committers group is made of clever persons that know we are all playing on top of a system that is bigger than us, that is
>>>> very complex and has been built thanks to the visions and great ideas/skills of others; we have to make sure we do not ruin what
>>>> we are asked to maintain and improve and, with such a big and complex beast, working together as a group is the only responsible
>>>> way of achieving this difficult task... on the other hand continuing to think as individuals with our own personal goals and ideas
>>>> will make a mess of this project soon
>>> I'd be very happy to see some sense of responsability to increase in the community. And I have the feeling that it's the case. We
>>> communicate better, and better respect each other ideas and ways. This said, there are huges task ahead...
>>>
>>> As I said in another email, I'm more for the step by step approach than to try a dramatic change,  ie more evolution thant
>>> revolution
>>>
>>> PS: to be more clear, when I speak about "step by step approach" I think about something like this part of a previous email:
>>>
>>>> 1) migrate the remaining Beanshell snippets to Groovy
>>>> 2) deprecate or remove (I see a lot of value in having lighter framework [*]) Beashell support (and other artifacts related to old/unused script engines)
>>>> 3) (optional, something for the future) refactor the GroovyUtil class (and code that is using it) to be generic (ScriptUtil) and convert all the calling code to use it in a Groovy unaware way; this will implement the JSR-223
>>>>
>>>> In this way, when we will work on #3 we could concentrate only on migration of groovy classes rather than having to cope with several other technologies (removed at #2)
>>>>
>>>> Kind regards,
>>>>
>>>> Jacopo
>>>>
>>>> [*] In my opinion one of the main big steps that the OFBiz project should consider is to greatly slim down the framework and only support the technology we really need (picking the best for each task); then with a much smaller codebase, we will be able to quickly improve the framework (less code to maintain etc...) to be compliant with new standards etc.. (e.g. JSR-223). For example in this context: ideally the OFBiz project should have all the scripts implemented in Groovy (one technology) and a simple way to integrate other scripting languages; we could achieve this implementing JSR-223 so that even the OFBiz code would be using javax.script.* rather than groovy.* packages OR it would be also fine if we would still be using groovy.* packages but in a clean way (e.g. all calling code could use interfaces to hide Groovy specific code) so that adding a new script engine would be easy (but the support of the new script engine will not be included in the project to keep it light and focused)
>>> Then, when done (I mean not only this part but also some needeeed others), an approach like suggested by Adrian could be adopted...
>>>
>>> My 2cts
>>>
>>> Jacques
>>>
>>>
>>>> Jacopo
>>>>
>>>> On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote:
>>>>
>>>>> You are a lot more optimistic than I am. Despite the best efforts of PMC members to provide advice/guidance/suggestions,
>>>>> committers still do what they please. It's worth a try, but I don't have much hope for success.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/1/2012 1:48 PM, Jacopo Cappellato wrote:
>>>>>> On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> I understand the workflow you are suggesting - cut down the size of the existing framework and then switch to something else.
>>>>>>> In an ideal world we could do that. Unfortunately, we have a lot of committers who believe more is better, so while we're
>>>>>>> cutting down in one area, someone else will be adding code in another area.
>>>>>> Yes, I know what you mean: I still think that, if the goal is clear and the strategy makes sense (e.g. "simplify/standardize the
>>>>>> tools used, for example migrate everything from bsh to groovy, and then slim down the current framework to the bare minimum
>>>>>> technologies used by the official applications in order to simplify and renew the code base") we could try to work to get a
>>>>>> majority approval and a shared strategy and then everyone will have to stick to the plan and help to implement it... i.e.
>>>>>> working as a community rather than as individual with commit rights and different visions.
>>>>>>
>>>>>> Jacopo
>>>>

Re: Framework refactor

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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" <ja...@hotwaxmedia.com>
>>> I don't think it will be easy and actually it may be unfeasible but I see some good reasons for hope:
>>> 
>>> * the general discussion/vote would involve all committers and not only PMC members: everyone would be involved in the decision
>>> and in the responsibilities/consequences around it
>>> * our committers group is made of clever persons that know we are all playing on top of a system that is bigger than us, that is
>>> very complex and has been built thanks to the visions and great ideas/skills of others; we have to make sure we do not ruin what
>>> we are asked to maintain and improve and, with such a big and complex beast, working together as a group is the only responsible
>>> way of achieving this difficult task... on the other hand continuing to think as individuals with our own personal goals and ideas
>>> will make a mess of this project soon
>> 
>> I'd be very happy to see some sense of responsability to increase in the community. And I have the feeling that it's the case. We
>> communicate better, and better respect each other ideas and ways. This said, there are huges task ahead...
>> 
>> As I said in another email, I'm more for the step by step approach than to try a dramatic change,  ie more evolution thant
>> revolution
>> 
>> PS: to be more clear, when I speak about "step by step approach" I think about something like this part of a previous email:
>> 
>>> 1) migrate the remaining Beanshell snippets to Groovy
>>> 2) deprecate or remove (I see a lot of value in having lighter framework [*]) Beashell support (and other artifacts related to old/unused script engines)
>>> 3) (optional, something for the future) refactor the GroovyUtil class (and code that is using it) to be generic (ScriptUtil) and convert all the calling code to use it in a Groovy unaware way; this will implement the JSR-223
>>> 
>>> In this way, when we will work on #3 we could concentrate only on migration of groovy classes rather than having to cope with several other technologies (removed at #2)
>>> 
>>> Kind regards,
>>> 
>>> Jacopo
>>> 
>>> [*] In my opinion one of the main big steps that the OFBiz project should consider is to greatly slim down the framework and only support the technology we really need (picking the best for each task); then with a much smaller codebase, we will be able to quickly improve the framework (less code to maintain etc...) to be compliant with new standards etc.. (e.g. JSR-223). For example in this context: ideally the OFBiz project should have all the scripts implemented in Groovy (one technology) and a simple way to integrate other scripting languages; we could achieve this implementing JSR-223 so that even the OFBiz code would be using javax.script.* rather than groovy.* packages OR it would be also fine if we would still be using groovy.* packages but in a clean way (e.g. all calling code could use interfaces to hide Groovy specific code) so that adding a new script engine would be easy (but the support of the new script engine will not be included in the project to keep it light and focused)
>> 
>> Then, when done (I mean not only this part but also some needeeed others), an approach like suggested by Adrian could be adopted...
>> 
>> My 2cts
>> 
>> Jacques
>> 
>> 
>>> 
>>> Jacopo
>>> 
>>> On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote:
>>> 
>>>> You are a lot more optimistic than I am. Despite the best efforts of PMC members to provide advice/guidance/suggestions,
>>>> committers still do what they please. It's worth a try, but I don't have much hope for success.
>>>> 
>>>> -Adrian
>>>> 
>>>> On 3/1/2012 1:48 PM, Jacopo Cappellato wrote:
>>>>> On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote:
>>>>> 
>>>>>> I understand the workflow you are suggesting - cut down the size of the existing framework and then switch to something else.
>>>>>> In an ideal world we could do that. Unfortunately, we have a lot of committers who believe more is better, so while we're
>>>>>> cutting down in one area, someone else will be adding code in another area.
>>>>> Yes, I know what you mean: I still think that, if the goal is clear and the strategy makes sense (e.g. "simplify/standardize the
>>>>> tools used, for example migrate everything from bsh to groovy, and then slim down the current framework to the bare minimum
>>>>> technologies used by the official applications in order to simplify and renew the code base") we could try to work to get a
>>>>> majority approval and a shared strategy and then everyone will have to stick to the plan and help to implement it... i.e.
>>>>> working as a community rather than as individual with commit rights and different visions.
>>>>> 
>>>>> Jacopo
>>> 
>>> 
> 

Re: Framework refactor

[Hans Bakker <ma...@antwebsystems.com>]

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" <ja...@hotwaxmedia.com>
>> I don't think it will be easy and actually it may be unfeasible but I 
>> see some good reasons for hope:
>>
>> * the general discussion/vote would involve all committers and not 
>> only PMC members: everyone would be involved in the decision
>> and in the responsibilities/consequences around it
>> * our committers group is made of clever persons that know we are all 
>> playing on top of a system that is bigger than us, that is
>> very complex and has been built thanks to the visions and great 
>> ideas/skills of others; we have to make sure we do not ruin what
>> we are asked to maintain and improve and, with such a big and complex 
>> beast, working together as a group is the only responsible
>> way of achieving this difficult task... on the other hand continuing 
>> to think as individuals with our own personal goals and ideas
>> will make a mess of this project soon
>
> I'd be very happy to see some sense of responsability to increase in 
> the community. And I have the feeling that it's the case. We
> communicate better, and better respect each other ideas and ways. This 
> said, there are huges task ahead...
>
> As I said in another email, I'm more for the step by step approach 
> than to try a dramatic change,  ie more evolution thant
> revolution
>
> PS: to be more clear, when I speak about "step by step approach" I 
> think about something like this part of a previous email:
>
>> 1) migrate the remaining Beanshell snippets to Groovy
>> 2) deprecate or remove (I see a lot of value in having lighter 
>> framework [*]) Beashell support (and other artifacts related to 
>> old/unused script engines)
>> 3) (optional, something for the future) refactor the GroovyUtil class 
>> (and code that is using it) to be generic (ScriptUtil) and convert 
>> all the calling code to use it in a Groovy unaware way; this will 
>> implement the JSR-223
>>
>> In this way, when we will work on #3 we could concentrate only on 
>> migration of groovy classes rather than having to cope with several 
>> other technologies (removed at #2)
>>
>> Kind regards,
>>
>> Jacopo
>>
>> [*] In my opinion one of the main big steps that the OFBiz project 
>> should consider is to greatly slim down the framework and only 
>> support the technology we really need (picking the best for each 
>> task); then with a much smaller codebase, we will be able to quickly 
>> improve the framework (less code to maintain etc...) to be compliant 
>> with new standards etc.. (e.g. JSR-223). For example in this context: 
>> ideally the OFBiz project should have all the scripts implemented in 
>> Groovy (one technology) and a simple way to integrate other scripting 
>> languages; we could achieve this implementing JSR-223 so that even 
>> the OFBiz code would be using javax.script.* rather than groovy.* 
>> packages OR it would be also fine if we would still be using groovy.* 
>> packages but in a clean way (e.g. all calling code could use 
>> interfaces to hide Groovy specific code) so that adding a new script 
>> engine would be easy (but the support of the new script engine will 
>> not be included in the project to keep it light and focused)
>
> Then, when done (I mean not only this part but also some needeeed 
> others), an approach like suggested by Adrian could be adopted...
>
> My 2cts
>
> Jacques
>
>
>>
>> Jacopo
>>
>> On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote:
>>
>>> You are a lot more optimistic than I am. Despite the best efforts of 
>>> PMC members to provide advice/guidance/suggestions,
>>> committers still do what they please. It's worth a try, but I don't 
>>> have much hope for success.
>>>
>>> -Adrian
>>>
>>> On 3/1/2012 1:48 PM, Jacopo Cappellato wrote:
>>>> On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote:
>>>>
>>>>> I understand the workflow you are suggesting - cut down the size 
>>>>> of the existing framework and then switch to something else.
>>>>> In an ideal world we could do that. Unfortunately, we have a lot 
>>>>> of committers who believe more is better, so while we're
>>>>> cutting down in one area, someone else will be adding code in 
>>>>> another area.
>>>> Yes, I know what you mean: I still think that, if the goal is clear 
>>>> and the strategy makes sense (e.g. "simplify/standardize the
>>>> tools used, for example migrate everything from bsh to groovy, and 
>>>> then slim down the current framework to the bare minimum
>>>> technologies used by the official applications in order to simplify 
>>>> and renew the code base") we could try to work to get a
>>>> majority approval and a shared strategy and then everyone will have 
>>>> to stick to the plan and help to implement it... i.e.
>>>> working as a community rather than as individual with commit rights 
>>>> and different visions.
>>>>
>>>> Jacopo
>>
>>

Re: Framework refactor

[Jacques Le Roux <ja...@les7arts.com>]

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>I don't think it will be easy and actually it may be unfeasible but I see some good reasons for hope:
>
> * the general discussion/vote would involve all committers and not only PMC members: everyone would be involved in the decision
> and in the responsibilities/consequences around it
> * our committers group is made of clever persons that know we are all playing on top of a system that is bigger than us, that is
> very complex and has been built thanks to the visions and great ideas/skills of others; we have to make sure we do not ruin what
> we are asked to maintain and improve and, with such a big and complex beast, working together as a group is the only responsible
> way of achieving this difficult task... on the other hand continuing to think as individuals with our own personal goals and ideas
> will make a mess of this project soon

I'd be very happy to see some sense of responsability to increase in the community. And I have the feeling that it's the case. We
communicate better, and better respect each other ideas and ways. This said, there are huges task ahead...

As I said in another email, I'm more for the step by step approach than to try a dramatic change,  ie more evolution thant
revolution

PS: to be more clear, when I speak about "step by step approach" I think about something like this part of a previous email:

> 1) migrate the remaining Beanshell snippets to Groovy
> 2) deprecate or remove (I see a lot of value in having lighter framework [*]) Beashell support (and other artifacts related to 
> old/unused script engines)
> 3) (optional, something for the future) refactor the GroovyUtil class (and code that is using it) to be generic (ScriptUtil) and 
> convert all the calling code to use it in a Groovy unaware way; this will implement the JSR-223
>
> In this way, when we will work on #3 we could concentrate only on migration of groovy classes rather than having to cope with 
> several other technologies (removed at #2)
>
> Kind regards,
>
> Jacopo
>
> [*] In my opinion one of the main big steps that the OFBiz project should consider is to greatly slim down the framework and only 
> support the technology we really need (picking the best for each task); then with a much smaller codebase, we will be able to 
> quickly improve the framework (less code to maintain etc...) to be compliant with new standards etc.. (e.g. JSR-223). For example 
> in this context: ideally the OFBiz project should have all the scripts implemented in Groovy (one technology) and a simple way to 
> integrate other scripting languages; we could achieve this implementing JSR-223 so that even the OFBiz code would be using 
> javax.script.* rather than groovy.* packages OR it would be also fine if we would still be using groovy.* packages but in a clean 
> way (e.g. all calling code could use interfaces to hide Groovy specific code) so that adding a new script engine would be easy 
> (but the support of the new script engine will not be included in the project to keep it light and focused)

Then, when done (I mean not only this part but also some needeeed others), an approach like suggested by Adrian could be adopted...

My 2cts

Jacques


>
> Jacopo
>
> On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote:
>
>> You are a lot more optimistic than I am. Despite the best efforts of PMC members to provide advice/guidance/suggestions,
>> committers still do what they please. It's worth a try, but I don't have much hope for success.
>>
>> -Adrian
>>
>> On 3/1/2012 1:48 PM, Jacopo Cappellato wrote:
>>> On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote:
>>>
>>>> I understand the workflow you are suggesting - cut down the size of the existing framework and then switch to something else.
>>>> In an ideal world we could do that. Unfortunately, we have a lot of committers who believe more is better, so while we're
>>>> cutting down in one area, someone else will be adding code in another area.
>>> Yes, I know what you mean: I still think that, if the goal is clear and the strategy makes sense (e.g. "simplify/standardize the
>>> tools used, for example migrate everything from bsh to groovy, and then slim down the current framework to the bare minimum
>>> technologies used by the official applications in order to simplify and renew the code base") we could try to work to get a
>>> majority approval and a shared strategy and then everyone will have to stick to the plan and help to implement it... i.e.
>>> working as a community rather than as individual with commit rights and different visions.
>>>
>>> Jacopo
>
>

Re: Framework refactor

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

I don't think it will be easy and actually it may be unfeasible but I see some good reasons for hope:

* the general discussion/vote would involve all committers and not only PMC members: everyone would be involved in the decision and in the responsibilities/consequences around it
* our committers group is made of clever persons that know we are all playing on top of a system that is bigger than us, that is very complex and has been built thanks to the visions and great ideas/skills of others; we have to make sure we do not ruin what we are asked to maintain and improve and, with such a big and complex beast, working together as a group is the only responsible way of achieving this difficult task... on the other hand continuing to think as individuals with our own personal goals and ideas will make a mess of this project soon

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

Re: Framework refactor

[Adrian Crum <ad...@sandglass-software.com>]

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

Re: Framework refactor (was: Definitively remove beanshell from OFBiz)

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Framework refactor (was: Definitively remove beanshell from OFBiz)

[Adrian Crum <ad...@sandglass-software.com>]

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"<er...@gmail.com>
>>>>>>> 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

Re: Definitively remove beanshell from OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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"<er...@gmail.com>
>>>>>> 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
> 

Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)

[Adrian Crum <ad...@sandglass-software.com>]

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" <ad...@sandglass-software.com>
>> 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" <ad...@sandglass-software.com>
>>>> 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
>>>>>>
>>>>>>
>>>>>>

Re: Implementing JSR-223

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Implementing JSR-223

[Upep à les7arts <up...@les7arts.com>]

From: "Nicolas Malin" <ma...@librenberry.net>
> Le 05/03/2012 10:08, Adrian Crum a écrit :
>> Because the value attribute is supposed to represent a string constant (that can be converted to another type via the type 
>> attribute), and the from-field attribute is supposed to represent a variable.
>>
>> My preference is to have a from-expression attribute to make things clearer.
>
> Same opinion, the from-expression miss to separate the value origin:

I guess you meant from-field above ;o)

Jacques

>  * from-field : provide only from existent context field
>  * value : only given value (Parsing by the given type)
>  * from-expression : calling script interface to resolve value.
>
>>
>> From my perspective, the main reason mini-language has such strange and quirky behavior is because the syntax has not been 
>> clearly expressed or implemented.
>>
>> -Adrian
>>
>> On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
>>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>>> 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.
>>>
>>> Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated 
>>> expressions (being in a script or inlined)
>>>
>>> Jacques
>>>
>>>> -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"<ad...@sandglass-software.com>
>>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>
>
> -- 
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
> 

Re: Implementing JSR-223

[Nicolas Malin <ma...@librenberry.net>]

Le 05/03/2012 10:08, Adrian Crum a écrit :
> Because the value attribute is supposed to represent a string constant 
> (that can be converted to another type via the type attribute), and 
> the from-field attribute is supposed to represent a variable.
>
> My preference is to have a from-expression attribute to make things 
> clearer.

Same opinion, the from-expression miss to separate the value origin:
  * from-field : provide only from existent context field
  * value : only given value (Parsing by the given type)
  * from-expression : calling script interface to resolve value.

>
> From my perspective, the main reason mini-language has such strange 
> and quirky behavior is because the syntax has not been clearly 
> expressed or implemented.
>
> -Adrian
>
> On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>> 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.
>>
>> Why? I'd prefer to stay the same than now. I agree it's a convention, 
>> but from-field makes less sense to me for evaluated expressions 
>> (being in a script or inlined)
>>
>> Jacques
>>
>>> -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"<ad...@sandglass-software.com>
>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>


-- 
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/

Re: Implementing JSR-223

[Jacques Le Roux <ja...@les7arts.com>]

Mmm... from-expression indeed.... This remembered me a discussion we had already
http://markmail.org/message/dzljmdhg2c3i52aq

No time to re-read at the moment, but yes from-expression sounds good to me and not that hard to change in current code.

Jacques


From: "Adrian Crum" <ad...@sandglass-software.com>
> Because the value attribute is supposed to represent a string constant 
> (that can be converted to another type via the type attribute), and the 
> from-field attribute is supposed to represent a variable.
> 
> My preference is to have a from-expression attribute to make things clearer.
> 
> From my perspective, the main reason mini-language has such strange and 
> quirky behavior is because the syntax has not been clearly expressed or 
> implemented.
> 
> -Adrian
> 
> On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>> 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.
>>
>> Why? I'd prefer to stay the same than now. I agree it's a convention, 
>> but from-field makes less sense to me for evaluated expressions (being 
>> in a script or inlined)
>>
>> Jacques
>>
>>> -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"<ad...@sandglass-software.com>
>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

Because the value attribute is supposed to represent a string constant 
(that can be converted to another type via the type attribute), and the 
from-field attribute is supposed to represent a variable.

My preference is to have a from-expression attribute to make things clearer.

 From my perspective, the main reason mini-language has such strange and 
quirky behavior is because the syntax has not been clearly expressed or 
implemented.

-Adrian

On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@sandglass-software.com>
>> 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.
>
> Why? I'd prefer to stay the same than now. I agree it's a convention, 
> but from-field makes less sense to me for evaluated expressions (being 
> in a script or inlined)
>
> Jacques
>
>> -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"<ad...@sandglass-software.com>
>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

Re: Implementing JSR-223

[Jacques Le Roux <ja...@les7arts.com>]

From: "Adrian Crum" <ad...@sandglass-software.com>
> 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.

Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated 
expressions (being in a script or inlined)

Jacques

> -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"<ad...@sandglass-software.com>
>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

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"<ad...@sandglass-software.com>
>>>>> 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"<ad...@sandglass-software.com>
>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

Re: Implementing JSR-223

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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"<ad...@sandglass-software.com>
>>>> 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"<ad...@sandglass-software.com>
>>>>>> 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
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

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"<ad...@sandglass-software.com>
>>> 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"<ad...@sandglass-software.com>
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>

Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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" <ad...@sandglass-software.com>
>> 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" <ad...@sandglass-software.com>
>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 

Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)

[Jacques Le Roux <ja...@les7arts.com>]

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" <ad...@sandglass-software.com>
> 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" <ad...@sandglass-software.com>
>>> 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
>>>>>
>>>>>
>>>>>

Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)

[Adrian Crum <ad...@sandglass-software.com>]

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" <ad...@sandglass-software.com>
>> 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
>>>>
>>>>
>>>>

Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)

[Jacques Le Roux <ja...@les7arts.com>]

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" <ad...@sandglass-software.com>
> 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
>>>
>>>
>>>

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

I finished my work on this integration in rev 1299924. We now have a 
basic scripting framework that developers can extend by adding scripting 
language engines. The framework includes a script helper class that is 
based on Jacopo's DSL idea. Scripts can access the helper class using 
the "ofbiz" variable.

There is still some work left to do to complete this task - various bits 
of framework code that invoke scripts need to use the new ScriptUtil 
class instead of whatever they are using now. Also, the JavaDocs are 
incomplete. I will leave those tasks for others to complete.

As I mentioned previously, there is a name clash with the "context" 
variable that might cause problems. I added a "widget" variable to take 
its place, so scripts that reference "context" need to be changed to 
reference "widget" instead. By the way, BSH uses the "script" variable 
name for its own helper class - that's why we use the "ofbiz" variable 
name. I'm sure we will encounter other surprises as this is built out.

-Adrian


On 3/11/2012 4:32 PM, Adrian Crum wrote:
> Since the "context" binding (variable) is used only in scripts run 
> from screen widgets, I was thinking we could rename it "widget" - 
> which has the added benefit of making operations on it more meaningful.
>
> To summarize: service and event scripts return values via the 
> "results" binding, and screen widget scripts return values via the 
> "widget" binding.
>
> What do you think?
>
> -Adrian
>
> On 3/6/2012 9:17 AM, Adrian Crum wrote:
>> I was thinking of using _context. I know we try to stay away from 
>> leading underscores as a general practice, but in this case I thought 
>> it would make the replacement (and learning curve) easier.
>>
>> -Adrian
>>
>> On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:
>>> I would be in favor of bulk renaming all the "context" variables in 
>>> our scripts... maybe we could wait after the creation of the 12.04 
>>> release branch... but I would be in favor even if we do this earlier.
>>>
>>> Jacopo
>>>
>>> On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
>>>
>>>> Update: I added a generic ScriptEngine to the service engine in rev 
>>>> 1297323.
>>>>
>>>> I haven't updated screen widgets and mini-lang to use JSR-223 
>>>> because there is a compatibility problem. In JSR-223, the "context" 
>>>> binding is reserved for the ScriptContext object, so any script 
>>>> code that uses the variable "context" will be using the 
>>>> ScriptContext object - not the context Map. I'm not sure how to 
>>>> proceed from here.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
>>>>> This could work but I was thinking to something more like having 
>>>>> some "core" packages (like entity and service) always imported in 
>>>>> groovy scripts/services; or having the "delegator" and 
>>>>> "dispatcher" objects properly casted to their interfaces (to take 
>>>>> advantage of IDE autocompletion features); etc...
>>>>> But I don't have a clear list at the moment so please do not 
>>>>> consider my notes a blocker.
>>>>> I am working at a POC for a "best practice" Groovy service 
>>>>> implementation and this should end up with a "wish list" of 
>>>>> features I would like to have. Then we can discuss the best way to 
>>>>> achieve this.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>>
>>>>>> If you don't mind, I would like to get all of the issues resolved 
>>>>>> during the design phase.
>>>>>>
>>>>>> I will wait for the private email to understand what you mean by 
>>>>>> a "secure" scripting package.
>>>>>>
>>>>>> What I was suggesting is a script utility object that can be put 
>>>>>> in the context so that all scripting languages can use it. 
>>>>>> Whatever methods you have in mind could be implemented in a 
>>>>>> generic way and reused. Personally, I would like to use something 
>>>>>> like:
>>>>>>
>>>>>> // Groovy, JavaScript
>>>>>> partyValue = script.entityOne("Party");
>>>>>> if (partyValue)...
>>>>>>
>>>>>> In other words, have an object in the context that gives us the 
>>>>>> convenience of mini-language.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

Since the "context" binding (variable) is used only in scripts run from 
screen widgets, I was thinking we could rename it "widget" - which has 
the added benefit of making operations on it more meaningful.

To summarize: service and event scripts return values via the "results" 
binding, and screen widget scripts return values via the "widget" binding.

What do you think?

-Adrian

On 3/6/2012 9:17 AM, Adrian Crum wrote:
> I was thinking of using _context. I know we try to stay away from 
> leading underscores as a general practice, but in this case I thought 
> it would make the replacement (and learning curve) easier.
>
> -Adrian
>
> On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:
>> I would be in favor of bulk renaming all the "context" variables in 
>> our scripts... maybe we could wait after the creation of the 12.04 
>> release branch... but I would be in favor even if we do this earlier.
>>
>> Jacopo
>>
>> On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
>>
>>> Update: I added a generic ScriptEngine to the service engine in rev 
>>> 1297323.
>>>
>>> I haven't updated screen widgets and mini-lang to use JSR-223 
>>> because there is a compatibility problem. In JSR-223, the "context" 
>>> binding is reserved for the ScriptContext object, so any script code 
>>> that uses the variable "context" will be using the ScriptContext 
>>> object - not the context Map. I'm not sure how to proceed from here.
>>>
>>> -Adrian
>>>
>>> On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
>>>> This could work but I was thinking to something more like having 
>>>> some "core" packages (like entity and service) always imported in 
>>>> groovy scripts/services; or having the "delegator" and "dispatcher" 
>>>> objects properly casted to their interfaces (to take advantage of 
>>>> IDE autocompletion features); etc...
>>>> But I don't have a clear list at the moment so please do not 
>>>> consider my notes a blocker.
>>>> I am working at a POC for a "best practice" Groovy service 
>>>> implementation and this should end up with a "wish list" of 
>>>> features I would like to have. Then we can discuss the best way to 
>>>> achieve this.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>
>>>>> If you don't mind, I would like to get all of the issues resolved 
>>>>> during the design phase.
>>>>>
>>>>> I will wait for the private email to understand what you mean by a 
>>>>> "secure" scripting package.
>>>>>
>>>>> What I was suggesting is a script utility object that can be put 
>>>>> in the context so that all scripting languages can use it. 
>>>>> Whatever methods you have in mind could be implemented in a 
>>>>> generic way and reused. Personally, I would like to use something 
>>>>> like:
>>>>>
>>>>> // Groovy, JavaScript
>>>>> partyValue = script.entityOne("Party");
>>>>> if (partyValue)...
>>>>>
>>>>> In other words, have an object in the context that gives us the 
>>>>> convenience of mini-language.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

I was thinking of using _context. I know we try to stay away from 
leading underscores as a general practice, but in this case I thought it 
would make the replacement (and learning curve) easier.

-Adrian

On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:
> I would be in favor of bulk renaming all the "context" variables in our scripts... maybe we could wait after the creation of the 12.04 release branch... but I would be in favor even if we do this earlier.
>
> Jacopo
>
> On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
>
>> Update: I added a generic ScriptEngine to the service engine in rev 1297323.
>>
>> I haven't updated screen widgets and mini-lang to use JSR-223 because there is a compatibility problem. In JSR-223, the "context" binding is reserved for the ScriptContext object, so any script code that uses the variable "context" will be using the ScriptContext object - not the context Map. I'm not sure how to proceed from here.
>>
>> -Adrian
>>
>> On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>>
>>> Jacopo
>>>
>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>
>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>>
>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>>
>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>>
>>>> // Groovy, JavaScript
>>>> partyValue = script.entityOne("Party");
>>>> if (partyValue)...
>>>>
>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

Re: Implementing JSR-223

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

I would be in favor of bulk renaming all the "context" variables in our scripts... maybe we could wait after the creation of the 12.04 release branch... but I would be in favor even if we do this earlier.

Jacopo

On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:

> Update: I added a generic ScriptEngine to the service engine in rev 1297323.
> 
> I haven't updated screen widgets and mini-lang to use JSR-223 because there is a compatibility problem. In JSR-223, the "context" binding is reserved for the ScriptContext object, so any script code that uses the variable "context" will be using the ScriptContext object - not the context Map. I'm not sure how to proceed from here.
> 
> -Adrian
> 
> On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>> 
>> Jacopo
>> 
>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>> 
>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>> 
>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>> 
>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>> 
>>> // Groovy, JavaScript
>>> partyValue = script.entityOne("Party");
>>> if (partyValue)...
>>> 
>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>> 
>>> -Adrian
>>> 
>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>> 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
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

Update: I added a generic ScriptEngine to the service engine in rev 1297323.

I haven't updated screen widgets and mini-lang to use JSR-223 because 
there is a compatibility problem. In JSR-223, the "context" binding is 
reserved for the ScriptContext object, so any script code that uses the 
variable "context" will be using the ScriptContext object - not the 
context Map. I'm not sure how to proceed from here.

-Adrian

On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
> But I don't have a clear list at the moment so please do not consider my notes a blocker.
> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>
> Jacopo
>
> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>
>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>
>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>
>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>
>> // Groovy, JavaScript
>> partyValue = script.entityOne("Party");
>> if (partyValue)...
>>
>> In other words, have an object in the context that gives us the convenience of mini-language.
>>
>> -Adrian
>>
>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

Now that we have the basic framework working, we can explore this idea 
further.

Right now we have ScriptHelper object available through the key "ofbiz". 
The object is retrieved from a single ScriptHelperFactory  instance.

If we made the getInstance method of ScriptHelperFactory return a 
java.lang.Object, then any number of factories could be used to add any 
number of custom helper objects to the bindings.

-Adrian

On 3/6/2012 11:49 PM, Scott Gray wrote:
> I'm not sure I follow what you're saying.  I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features.
>
> I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice.  I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating.
>
> Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need.
>
> Regards
> Scott
>
> On 7/03/2012, at 12:33 PM, Adrian Crum wrote:
>
>> The EntityConditionBuilder class is a good example of how we can make scripting more convenient.
>>
>> Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects.
>>
>> I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities.
>>
>> My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users.
>>
>> So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it.
>>
>> -Adrian
>>
>>
>> On 3/6/2012 10:23 AM, Scott Gray wrote:
>>> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>>>
>>> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
>>> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>>>
>>> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>>>
>>> Regards
>>> Scott
>>>
>>> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>>>
>>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>
>>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>>>
>>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>>>
>>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>>>
>>>>> // Groovy, JavaScript
>>>>> partyValue = script.entityOne("Party");
>>>>> if (partyValue)...
>>>>>
>>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

Re: Implementing JSR-223

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Yes, I agree with the general strategy: OFBiz will be (or it is) flexible and ready to be used with alternative tools; our effort as a community will be that of "opening it up" and slimming it down instead of trying to include all the possible alternative tools in our package; and the work that Adrian is doing to enable OFBiz to JSR-223 is a good example in this direction because it provides a flexible mechanism to plug in different scripting languages by just dropping the (JSR-223 compliant) jar files of the language of preference in the classpath; of course this will be a generic/basic support (i.e. the generic/basic one provided by JSR-223) and if the user will want to implement a library of custom objects to better structure the work in the new script then it will be fine, but these classes will not find a way to OFBiz because they will be custom and because they will be useless if you don't plan to use that specific language.
In a similar way the community has chosen for the OFBiz applications a scripting language of choice (currently Groovy) and this is the reason we have some Groovy friendly classes (shipped ootb) that are used by our Groovy scripts.

Jacopo

On Mar 7, 2012, at 12:58 AM, Adrian Crum wrote:

> Fair enough. Users of other scripting languages can adapt the code to suit their language.
> 
> -Adrian
> 
> On 3/6/2012 11:49 PM, Scott Gray wrote:
>> I'm not sure I follow what you're saying.  I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features.
>> 
>> I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice.  I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating.
>> 
>> Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need.
>> 
>> Regards
>> Scott
>> 
>> On 7/03/2012, at 12:33 PM, Adrian Crum wrote:
>> 
>>> The EntityConditionBuilder class is a good example of how we can make scripting more convenient.
>>> 
>>> Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects.
>>> 
>>> I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities.
>>> 
>>> My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users.
>>> 
>>> So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it.
>>> 
>>> -Adrian
>>> 
>>> 
>>> On 3/6/2012 10:23 AM, Scott Gray wrote:
>>>> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>>>> 
>>>> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
>>>> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>>>> 
>>>> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>>>> 
>>>> Regards
>>>> Scott
>>>> 
>>>> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>>>> 
>>>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>>>> 
>>>>> Jacopo
>>>>> 
>>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>> 
>>>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>>>> 
>>>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>>>> 
>>>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>>>> 
>>>>>> // Groovy, JavaScript
>>>>>> partyValue = script.entityOne("Party");
>>>>>> if (partyValue)...
>>>>>> 
>>>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>>>> 
>>>>>> -Adrian
>>>>>> 
>>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>>> 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
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

Fair enough. Users of other scripting languages can adapt the code to 
suit their language.

-Adrian

On 3/6/2012 11:49 PM, Scott Gray wrote:
> I'm not sure I follow what you're saying.  I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features.
>
> I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice.  I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating.
>
> Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need.
>
> Regards
> Scott
>
> On 7/03/2012, at 12:33 PM, Adrian Crum wrote:
>
>> The EntityConditionBuilder class is a good example of how we can make scripting more convenient.
>>
>> Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects.
>>
>> I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities.
>>
>> My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users.
>>
>> So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it.
>>
>> -Adrian
>>
>>
>> On 3/6/2012 10:23 AM, Scott Gray wrote:
>>> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>>>
>>> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
>>> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>>>
>>> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>>>
>>> Regards
>>> Scott
>>>
>>> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>>>
>>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>
>>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>>>
>>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>>>
>>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>>>
>>>>> // Groovy, JavaScript
>>>>> partyValue = script.entityOne("Party");
>>>>> if (partyValue)...
>>>>>
>>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

Re: Implementing JSR-223

[Scott Gray <sc...@hotwaxmedia.com>]

I'm not sure I follow what you're saying.  I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features.  

I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice.  I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating.

Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need.

Regards
Scott

On 7/03/2012, at 12:33 PM, Adrian Crum wrote:

> The EntityConditionBuilder class is a good example of how we can make scripting more convenient.
> 
> Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects.
> 
> I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities.
> 
> My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users.
> 
> So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it.
> 
> -Adrian
> 
> 
> On 3/6/2012 10:23 AM, Scott Gray wrote:
>> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>> 
>> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
>> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>> 
>> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>> 
>> Regards
>> Scott
>> 
>> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>> 
>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>> 
>>> Jacopo
>>> 
>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>> 
>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>> 
>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>> 
>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>> 
>>>> // Groovy, JavaScript
>>>> partyValue = script.entityOne("Party");
>>>> if (partyValue)...
>>>> 
>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>> 
>>>> -Adrian
>>>> 
>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

The EntityConditionBuilder class is a good example of how we can make 
scripting more convenient.

Different scripting languages will have varying support for Java 
classes. It was my hope that we could come up with a Java-based script 
helper class that can be used by a variety of scripting languages that 
can access Java objects.

I understand that there is an interest in Groovy in this community, but 
other communities might prefer a different language. For example, Jython 
and Ruby have sizable communities.

My motivation in in implementing JSR-223 is the same as my motivation to 
implement internationalization/globalization years ago - to open up the 
project to more users.

So, let's try to keep the big picture in mind. If we come up with a 
scripting convenience, let's try to accommodate the most users with it.

-Adrian


On 3/6/2012 10:23 AM, Scott Gray wrote:
> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>
> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>
> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>
> Regards
> Scott
>
> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>
>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>
>> Jacopo
>>
>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>
>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>
>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>
>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>
>>> // Groovy, JavaScript
>>> partyValue = script.entityOne("Party");
>>> if (partyValue)...
>>>
>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>
>>> -Adrian
>>>
>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

Re: Implementing JSR-223

[Scott Gray <sc...@hotwaxmedia.com>]

The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).

A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder

Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.

Regards
Scott

On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:

> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
> But I don't have a clear list at the moment so please do not consider my notes a blocker.
> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
> 
> Jacopo
> 
> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
> 
>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>> 
>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>> 
>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>> 
>> // Groovy, JavaScript
>> partyValue = script.entityOne("Party");
>> if (partyValue)...
>> 
>> In other words, have an object in the context that gives us the convenience of mini-language.
>> 
>> -Adrian
>> 
>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>> 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
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
> 

Re: Implementing JSR-223

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
But I don't have a clear list at the moment so please do not consider my notes a blocker.
I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.

Jacopo

On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:

> If you don't mind, I would like to get all of the issues resolved during the design phase.
> 
> I will wait for the private email to understand what you mean by a "secure" scripting package.
> 
> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
> 
> // Groovy, JavaScript
> partyValue = script.entityOne("Party");
> if (partyValue)...
> 
> In other words, have an object in the context that gives us the convenience of mini-language.
> 
> -Adrian
> 
> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>> 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
>>>>>>> 
>>>>>>> 
>>>>>>> 

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

If you don't mind, I would like to get all of the issues resolved during 
the design phase.

I will wait for the private email to understand what you mean by a 
"secure" scripting package.

What I was suggesting is a script utility object that can be put in the 
context so that all scripting languages can use it. Whatever methods you 
have in mind could be implemented in a generic way and reused. 
Personally, I would like to use something like:

// Groovy, JavaScript
partyValue = script.entityOne("Party");
if (partyValue)...

In other words, have an object in the context that gives us the 
convenience of mini-language.

-Adrian

On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
> 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
>>>>>>
>>>>>>
>>>>>>

Re: Implementing JSR-223

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Implementing JSR-223

[Adrian Crum <ad...@sandglass-software.com>]

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

Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)

[Adrian Crum <ad...@sandglass-software.com>]

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

Re: Definitively remove beanshell from OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Definitively remove beanshell from OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Definitively remove beanshell from OFBiz

[Adrian Crum <ad...@sandglass-software.com>]

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"<er...@gmail.com>
>>>>> 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

Re: Definitively remove beanshell from OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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" <er...@gmail.com>
>>>> 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

Re: Definitively remove beanshell from OFBiz

[Erwan de FERRIERES <er...@nereide.fr>]

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" <er...@gmail.com>
>>> 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

Re: Definitively remove beanshell from OFBiz

[Adrian Crum <ad...@sandglass-software.com>]

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" <er...@gmail.com>
>> 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

Re: Definitively remove beanshell from OFBiz

[Jacques Le Roux <ja...@les7arts.com>]

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

Jacques

From: "Erwan de FERRIERES" <er...@gmail.com>
> 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