Is groovy a must to learn OfBiz?

Question

Is it a must to know Groovy to start learning Ofbiz? The one book i can find is for version 4 of ofbiz and it uses Beanshell. I don't know if later versions of ofbiz have added support for groovy.

Objective: to create workflows as necessary. Thanks.

EDIT: Found this. From what i understand, one can use any compliant Java scripting language.However, Groovy will be supported OOTB. (Groovy is not just a scripting language, but it is one of the roles)

Answer 1

Later versions have added support for Groovy.

AFAIK, you can still use Beanshell if you want

Answer 2

No, you shouldn't, unless you want use not java but groovy to develop something - e.g, event, service - for OFBiz.

If you familiar with java, that's enough for you to read and understand the source code written in groovy, and it's enough in most case to write some simple in-line groovy script used in OFBiz.

"Know groovy", it's nice-to-have but not must to "start learning OFBiz".

Answer 3

Groovy is used a lot in screen actions, which is the data preparation code that is part of generating UI output. There is a lot of code in the project like this.

It can also be used to implement services and request events (used for processing input), and is a popular tool for custom extensions to OFBiz even though not used a lot in OFBiz itself.

As stated in other answers if you know Java it's easy to read most Groovy code (some closure syntax can be confusing at first), but it's worth learning about more to reduce code size and effort, and make your code cleaner and easier to maintain. In other words, Groovy has a lot of extensions beyond plain Java that are very useful, especially for business logic in applications like those built with Apache OFBiz.

As a case in point, the next generation framework based on the ideas in OFBiz (Moqui Framework, www.moqui.org) is written largely in Groovy and supports Groovy for everything whereas OFBiz also uses JUEL for expressions (and even Beanshell still in a couple places). I should note that both frameworks support a number of other scripting languages for business logic if you have other strong preferences, but it is nice to standardize on one so that developers have less to learn and can more easily work with existing business logic and (as applicable) framework code.