Discussion: move from Beanshell to Groovy

[David E Jones]

Thanks to some recent work from Joe Eckard OFBiz now has pretty good  
support for the Groovy scripting language.

While this is kind of interesting on its own, what was really  
interesting was to find out (after not looking at groovy for probably  
about 4 years) that it supports nearly all of the Java syntax, and in  
addition offers significant syntax sugar and functionality, including  
the dot syntax we like in FTL and various OFBiz XML elements/
attributes (though it is way better than any of those...).

The reason that point peaked my interest was because my main reason  
for sticking with bsh as the scripting language for OFBiz was that it  
follows the Java syntax and works with most JavaScript funny business  
too, and thus reduces the learning curve for both back-end and front-
end developers.

The downsides to bsh are somewhat significant, starting with the fact  
that it isn't so much a community driven project as it is one man's  
pet project, and to that point hasn't had a release in years. The  
functionality and performance of Beanshell also leaves a lot to be  
desired, especially compared to what Groovy now offers.

In spite of the fact that Groovy has received so much attention in the  
press and such in recent months (well, for over a year now), and there  
are funny/cool things like "Groovy on Grails" that exist, Groovy  
really is a good scripting language and has some impressive features  
to help with development efficiency, and makes up for many of the  
things that make Java and Beanshell cumbersome to use.

So, what I am proposing is that we change the best practice  
recommended scripting language in OFBiz from Beanshell to Groovy. This  
would mean eventually moving all .bsh files to .groovy files (which is  
fortunately easy because most, if not all, of the OFBiz bsh files will  
run as-is through groovy, though it would be good to clean things up  
as we go...).

The point of this thread is to open up the topic for discussion before  
doing anything like a vote.

So, please research, then comment!

-David

[Jacques Le Roux]

Thanks Joe, thanks David !

http://groovy.codehaus.org/Groovy+Console and http://groovy.codehaus.org/Eclipse+Plugin (+IntelliJ, etc.) , sound appealing too and
Groovy seems to give a lot of good support directly from its home page :o)

I know at least one OFBiz project which is already using groovy, this will please these folks !

Jacques

From: "David E Jones" <[hidden email]>

>
> Thanks to some recent work from Joe Eckard OFBiz now has pretty good  support for the Groovy scripting language.
>
> While this is kind of interesting on its own, what was really  interesting was to find out (after not looking at groovy for
> probably  about 4 years) that it supports nearly all of the Java syntax, and in  addition offers significant syntax sugar and
> functionality, including  the dot syntax we like in FTL and various OFBiz XML elements/ attributes (though it is way better than
> any of those...).
>
> The reason that point peaked my interest was because my main reason  for sticking with bsh as the scripting language for OFBiz was
> that it   follows the Java syntax and works with most JavaScript funny business  too, and thus reduces the learning curve for both
> back-end and front- end developers.
>
> The downsides to bsh are somewhat significant, starting with the fact  that it isn't so much a community driven project as it is
> one man's  pet project, and to that point hasn't had a release in years. The  functionality and performance of Beanshell also
> leaves a lot to be  desired, especially compared to what Groovy now offers.
>
> In spite of the fact that Groovy has received so much attention in the  press and such in recent months (well, for over a year
> now), and there  are funny/cool things like "Groovy on Grails" that exist, Groovy  really is a good scripting language and has
> some impressive features  to help with development efficiency, and makes up for many of the  things that make Java and Beanshell
> cumbersome to use.
>
> So, what I am proposing is that we change the best practice  recommended scripting language in OFBiz from Beanshell to Groovy.
> This  would mean eventually moving all .bsh files to .groovy files (which is  fortunately easy because most, if not all, of the
> OFBiz bsh files will  run as-is through groovy, though it would be good to clean things up  as we go...).
>
> The point of this thread is to open up the topic for discussion before  doing anything like a vote.
>
> So, please research, then comment!
>
> -David
>

[Jacopo Cappellato-3]

On May 19, 2008, at 10:07 AM, David E Jones wrote:

>
> Thanks to some recent work from Joe Eckard OFBiz now has pretty good  
> support for the Groovy scripting language.
>
> While this is kind of interesting on its own, what was really  
> interesting was to find out (after not looking at groovy for  
> probably about 4 years) that it supports nearly all of the Java  
> syntax, and in addition offers significant syntax sugar and  
> functionality, including the dot syntax we like in FTL and various  
> OFBiz XML elements/attributes (though it is way better than any of  
> those...).
>
> The reason that point peaked my interest was because my main reason  
> for sticking with bsh as the scripting language for OFBiz was that  
> it  follows the Java syntax and works with most JavaScript funny  
> business too, and thus reduces the learning curve for both back-end  
> and front-end developers.
>
> The downsides to bsh are somewhat significant, starting with the  
> fact that it isn't so much a community driven project as it is one  
> man's pet project, and to that point hasn't had a release in years.  
> The functionality and performance of Beanshell also leaves a lot to  
> be desired, especially compared to what Groovy now offers.
>
> In spite of the fact that Groovy has received so much attention in  
> the press and such in recent months (well, for over a year now), and  
> there are funny/cool things like "Groovy on Grails" that exist,  
> Groovy really is a good scripting language and has some impressive  
> features to help with development efficiency, and makes up for many  
> of the things that make Java and Beanshell cumbersome to use.
>
> So, what I am proposing is that we change the best practice  
> recommended scripting language in OFBiz from Beanshell to Groovy.  
> This would mean eventually moving all .bsh files to .groovy files  
> (which is fortunately easy because most, if not all, of the OFBiz  
> bsh files will run as-is through groovy, though it would be good to  
> clean things up as we go...).

It would be great to see this migration implemented soon.
In my opinion, the priority could be this:
1) change the best practice recommendation
2) migrate (with minimal changes/work) all the existing .bsh scripts  
to .groovy scripts
3) clean and improve the migrated scripts to take full advantage of  
the new language

We could implement #1 and #2 very soon in one big batch, while #3  
could be done over time (unless we can bulk change some of the code in  
the scripts).

Jacopo

>
>
> The point of this thread is to open up the topic for discussion  
> before doing anything like a vote.
>
> So, please research, then comment!
>
> -David
>

[Scott Gray]

Sounds like fun, when do we start? :-)

I haven't had a good look yet but I like the sound of dot syntax alone.

Regards
Scott

2008/5/19 Jacopo Cappellato <[hidden email]>:

>
> On May 19, 2008, at 10:07 AM, David E Jones wrote:
>
>
>> Thanks to some recent work from Joe Eckard OFBiz now has pretty good
>> support for the Groovy scripting language.
>>
>> While this is kind of interesting on its own, what was really interesting
>> was to find out (after not looking at groovy for probably about 4 years)
>> that it supports nearly all of the Java syntax, and in addition offers
>> significant syntax sugar and functionality, including the dot syntax we like
>> in FTL and various OFBiz XML elements/attributes (though it is way better
>> than any of those...).
>>
>> The reason that point peaked my interest was because my main reason for
>> sticking with bsh as the scripting language for OFBiz was that it  follows
>> the Java syntax and works with most JavaScript funny business too, and thus
>> reduces the learning curve for both back-end and front-end developers.
>>
>> The downsides to bsh are somewhat significant, starting with the fact that
>> it isn't so much a community driven project as it is one man's pet project,
>> and to that point hasn't had a release in years. The functionality and
>> performance of Beanshell also leaves a lot to be desired, especially
>> compared to what Groovy now offers.
>>
>> In spite of the fact that Groovy has received so much attention in the
>> press and such in recent months (well, for over a year now), and there are
>> funny/cool things like "Groovy on Grails" that exist, Groovy really is a
>> good scripting language and has some impressive features to help with
>> development efficiency, and makes up for many of the things that make Java
>> and Beanshell cumbersome to use.
>>
>> So, what I am proposing is that we change the best practice recommended
>> scripting language in OFBiz from Beanshell to Groovy. This would mean
>> eventually moving all .bsh files to .groovy files (which is fortunately easy
>> because most, if not all, of the OFBiz bsh files will run as-is through
>> groovy, though it would be good to clean things up as we go...).
>>
>
> It would be great to see this migration implemented soon.
> In my opinion, the priority could be this:
> 1) change the best practice recommendation
> 2) migrate (with minimal changes/work) all the existing .bsh scripts to
> .groovy scripts
> 3) clean and improve the migrated scripts to take full advantage of the new
> language
>
> We could implement #1 and #2 very soon in one big batch, while #3 could be
> done over time (unless we can bulk change some of the code in the scripts).
>
> Jacopo
>
>
>
>>
>> The point of this thread is to open up the topic for discussion before
>> doing anything like a vote.
>>
>> So, please research, then comment!
>>
>> -David
>>
>>
>

[Tim Ruppert]

+1 - this is a great idea.

On May 19, 2008, at 5:32 AM, Scott Gray wrote:

> Sounds like fun, when do we start? :-)
>
> I haven't had a good look yet but I like the sound of dot syntax  
> alone.
>
> Regards
> Scott
>
> 2008/5/19 Jacopo Cappellato <[hidden email]>:
>
>>
>> On May 19, 2008, at 10:07 AM, David E Jones wrote:
>>
>>
>>> Thanks to some recent work from Joe Eckard OFBiz now has pretty good
>>> support for the Groovy scripting language.
>>>
>>> While this is kind of interesting on its own, what was really  
>>> interesting
>>> was to find out (after not looking at groovy for probably about 4  
>>> years)
>>> that it supports nearly all of the Java syntax, and in addition  
>>> offers
>>> significant syntax sugar and functionality, including the dot  
>>> syntax we like
>>> in FTL and various OFBiz XML elements/attributes (though it is way  
>>> better
>>> than any of those...).
>>>
>>> The reason that point peaked my interest was because my main  
>>> reason for
>>> sticking with bsh as the scripting language for OFBiz was that it  
>>> follows
>>> the Java syntax and works with most JavaScript funny business too,  
>>> and thus
>>> reduces the learning curve for both back-end and front-end  
>>> developers.
>>>
>>> The downsides to bsh are somewhat significant, starting with the  
>>> fact that
>>> it isn't so much a community driven project as it is one man's pet  
>>> project,
>>> and to that point hasn't had a release in years. The functionality  
>>> and
>>> performance of Beanshell also leaves a lot to be desired, especially
>>> compared to what Groovy now offers.
>>>
>>> In spite of the fact that Groovy has received so much attention in  
>>> the
>>> press and such in recent months (well, for over a year now), and  
>>> there are
>>> funny/cool things like "Groovy on Grails" that exist, Groovy  
>>> really is a
>>> good scripting language and has some impressive features to help  
>>> with
>>> development efficiency, and makes up for many of the things that  
>>> make Java
>>> and Beanshell cumbersome to use.
>>>
>>> So, what I am proposing is that we change the best practice  
>>> recommended
>>> scripting language in OFBiz from Beanshell to Groovy. This would  
>>> mean
>>> eventually moving all .bsh files to .groovy files (which is  
>>> fortunately easy
>>> because most, if not all, of the OFBiz bsh files will run as-is  
>>> through
>>> groovy, though it would be good to clean things up as we go...).
>>>
>>
>> It would be great to see this migration implemented soon.
>> In my opinion, the priority could be this:
>> 1) change the best practice recommendation
>> 2) migrate (with minimal changes/work) all the existing .bsh  
>> scripts to
>> .groovy scripts
>> 3) clean and improve the migrated scripts to take full advantage of  
>> the new
>> language
>>
>> We could implement #1 and #2 very soon in one big batch, while #3  
>> could be
>> done over time (unless we can bulk change some of the code in the  
>> scripts).
>>
>> Jacopo
>>
>>
>>
>>>
>>> The point of this thread is to open up the topic for discussion  
>>> before
>>> doing anything like a vote.
>>>
>>> So, please research, then comment!
>>>
>>> -David
>>>
>>>
>>

[Ashish Vijaywargiya]

+1.


On Mon, May 19, 2008 at 9:28 AM, Tim Ruppert <[hidden email]>
wrote:

> +1 - this is a great idea.
>
>
> On May 19, 2008, at 5:32 AM, Scott Gray wrote:
>
>  Sounds like fun, when do we start? :-)
>>
>> I haven't had a good look yet but I like the sound of dot syntax alone.
>>
>> Regards
>> Scott
>>
>> 2008/5/19 Jacopo Cappellato <[hidden email]>:
>>
>>
>>> On May 19, 2008, at 10:07 AM, David E Jones wrote:
>>>
>>>
>>>  Thanks to some recent work from Joe Eckard OFBiz now has pretty good
>>>> support for the Groovy scripting language.
>>>>
>>>> While this is kind of interesting on its own, what was really
>>>> interesting
>>>> was to find out (after not looking at groovy for probably about 4 years)
>>>> that it supports nearly all of the Java syntax, and in addition offers
>>>> significant syntax sugar and functionality, including the dot syntax we
>>>> like
>>>> in FTL and various OFBiz XML elements/attributes (though it is way
>>>> better
>>>> than any of those...).
>>>>
>>>> The reason that point peaked my interest was because my main reason for
>>>> sticking with bsh as the scripting language for OFBiz was that it
>>>>  follows
>>>> the Java syntax and works with most JavaScript funny business too, and
>>>> thus
>>>> reduces the learning curve for both back-end and front-end developers.
>>>>
>>>> The downsides to bsh are somewhat significant, starting with the fact
>>>> that
>>>> it isn't so much a community driven project as it is one man's pet
>>>> project,
>>>> and to that point hasn't had a release in years. The functionality and
>>>> performance of Beanshell also leaves a lot to be desired, especially
>>>> compared to what Groovy now offers.
>>>>
>>>> In spite of the fact that Groovy has received so much attention in the
>>>> press and such in recent months (well, for over a year now), and there
>>>> are
>>>> funny/cool things like "Groovy on Grails" that exist, Groovy really is a
>>>> good scripting language and has some impressive features to help with
>>>> development efficiency, and makes up for many of the things that make
>>>> Java
>>>> and Beanshell cumbersome to use.
>>>>
>>>> So, what I am proposing is that we change the best practice recommended
>>>> scripting language in OFBiz from Beanshell to Groovy. This would mean
>>>> eventually moving all .bsh files to .groovy files (which is fortunately
>>>> easy
>>>> because most, if not all, of the OFBiz bsh files will run as-is through
>>>> groovy, though it would be good to clean things up as we go...).
>>>>
>>>>
>>> It would be great to see this migration implemented soon.
>>> In my opinion, the priority could be this:
>>> 1) change the best practice recommendation
>>> 2) migrate (with minimal changes/work) all the existing .bsh scripts to
>>> .groovy scripts
>>> 3) clean and improve the migrated scripts to take full advantage of the
>>> new
>>> language
>>>
>>> We could implement #1 and #2 very soon in one big batch, while #3 could
>>> be
>>> done over time (unless we can bulk change some of the code in the
>>> scripts).
>>>
>>> Jacopo
>>>
>>>
>>>
>>>
>>>> The point of this thread is to open up the topic for discussion before
>>>> doing anything like a vote.
>>>>
>>>> So, please research, then comment!
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>
>

--
Thanks & Regards
Ashish Vijaywargiya
[phone]

[Joe Eckard]

+1

On May 19, 2008, at 6:27 AM, Jacopo Cappellato wrote:

> It would be great to see this migration implemented soon.
> In my opinion, the priority could be this:
> 1) change the best practice recommendation
> 2) migrate (with minimal changes/work) all the existing .bsh scripts  
> to .groovy scripts

I think this step would be fairly easy - just rename all of the .bsh  
scripts to .groovy - however a catch with our existing scripts is that  
when you have a script fragment with no class declaration, the script  
name becomes the class name, e.g. category.bsh becomes category and  
then you can't have an untyped variable named "category" in that  
script, since it conflicts with the class. The suggested workaround is  
to not use lowercase filenames (switch to Category.groovy) or to  
explicitly type the category variable.

>
> 3) clean and improve the migrated scripts to take full advantage of  
> the new language
>
> We could implement #1 and #2 very soon in one big batch, while #3  
> could be done over time (unless we can bulk change some of the code  
> in the scripts).
>
> Jacopo

[Ean Schuessler]

----- "Jacques Le Roux" <[hidden email]> wrote:

> I know at least one OFBiz project which is already using groovy, this
> will please these folks !

I know we're happy to hear about it! Adam and I have been talking for a while about stuff like:

ofbiz.services.createPerson([firstName: 'John', lastName: 'Doe'])

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315

[Tim Ruppert]

Yeah - great stuff!  Ean, what are your thoughts on GSP?  Any other  
ideas on the templating side that seem like a big win?

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On May 19, 2008, at 10:58 AM, Ean Schuessler wrote:

>
> ----- "Jacques Le Roux" <[hidden email]> wrote:
>
>> I know at least one OFBiz project which is already using groovy, this
>> will please these folks !
>
> I know we're happy to hear about it! Adam and I have been talking  
> for a while about stuff like:
>
> ofbiz.services.createPerson([firstName: 'John', lastName: 'Doe'])
>
> --
> Ean Schuessler, CTO Brainfood.com
> [hidden email] - http://www.brainfood.com - 214-720-0700 x 315

[Ean Schuessler]

----- "Tim Ruppert" <[hidden email]> wrote:

> Yeah - great stuff!  Ean, what are your thoughts on GSP?  Any other  
> ideas on the templating side that seem like a big win?

We've settled on running Groovy events for most of our page setup that interacts with the OFBiz business logic and then dropping the result into Velocity templates. The benefit there is that Velocity is a much more constrained environment that makes it hard for people with content editing level access to access lower level controls.

As you know, we've been working on a templating design that allows a more incremental development approach. We wanted to make the whole page framework a lot more malleable at runtime without requiring a lot of restarts and we have some awesome progress in that department. We definitely want to open this stuff up to the community at large and just need to get some time to produce some introductory documentation and videos so that we aren't trying to answer questions in one-on-one email.

We have definitely done some new things with templating that I'm not aware of any other system offering. We've created a system of web site inheritance that allows sites to fractionally override a master template site. This is a very useful way to change the behavior of things like an ecommerce site without having to copy and modify the entire baseline.

I really need to dig back into the OFBiz widgets and see what we can do to bond the FormWidget framework into our model. At the same time, I've been evaluating things like Google Gadgets and GWT to see if that is the way to go. For certain, I'm not satisfied with any of the form handling and GUI building we currently have. That's not a reflection on the quality of work that has been done, because there is tons of good stuff there, but rather where I think we need to be to compete with the cutting edge in consumer facing websites.

Slight left turn, I think there is very interesting potential in building a gateway between the OFBiz party model and the Open Social initiative. It is hard to say whether that is a portal technology or a GUI technology or both.

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315

[Tim Ruppert]

Inline

On May 20, 2008, at 1:53 PM, Ean Schuessler wrote:

>
> ----- "Tim Ruppert" <[hidden email]> wrote:
>
>> Yeah - great stuff!  Ean, what are your thoughts on GSP?  Any other
>> ideas on the templating side that seem like a big win?
>
> We've settled on running Groovy events for most of our page setup  
> that interacts with the OFBiz business logic and then dropping the  
> result into Velocity templates. The benefit there is that Velocity  
> is a much more constrained environment that makes it hard for people  
> with content editing level access to access lower level controls.

Yep - looks like communities about to follow suit!  On Velocity, I  
haven't used it that much, so I don't know all of the benefits - it  
would be interesting to revisit it in this context.

> As you know, we've been working on a templating design that allows a  
> more incremental development approach. We wanted to make the whole  
> page framework a lot more malleable at runtime without requiring a  
> lot of restarts and we have some awesome progress in that  
> department. We definitely want to open this stuff up to the  
> community at large and just need to get some time to produce some  
> introductory documentation and videos so that we aren't trying to  
> answer questions in one-on-one email.
>
> We have definitely done some new things with templating that I'm not  
> aware of any other system offering. We've created a system of web  
> site inheritance that allows sites to fractionally override a master  
> template site. This is a very useful way to change the behavior of  
> things like an ecommerce site without having to copy and modify the  
> entire baseline.

Dude, as I've been saying for over a year now, we need to get this  
stuff back into the project.  The ideas are solid and have an  
opportunity to make a difference in the way that people develop apps  
on OFBiz.

> I really need to dig back into the OFBiz widgets and see what we can  
> do to bond the FormWidget framework into our model. At the same  
> time, I've been evaluating things like Google Gadgets and GWT to see  
> if that is the way to go. For certain, I'm not satisfied with any of  
> the form handling and GUI building we currently have. That's not a  
> reflection on the quality of work that has been done, because there  
> is tons of good stuff there, but rather where I think we need to be  
> to compete with the cutting edge in consumer facing websites.

I'm not a huge fan of any of the Google front end code they've been  
developing.  We tend to do things at a bit more of a lower level, but  
we're trying to get some of that into screen widgets so it's a bit  
more reusable as well.

> Slight left turn, I think there is very interesting potential in  
> building a gateway between the OFBiz party model and the Open Social  
> initiative. It is hard to say whether that is a portal technology or  
> a GUI technology or both.

+1

>
> --
> Ean Schuessler, CTO Brainfood.com
> [hidden email] - http://www.brainfood.com - 214-720-0700 x 315