In a 1st time I intend to do only what I wrote in OFBIZ-10226, OFBIZ-10205 and this thread, ie indeed mostly "move them to src/main/groovy". That's enough for my need.

Using @CompileStatic is out of my scope because I want to keep Groovy scripts 
dynamic.

Le 20/09/2019 à 16:27, Taher Alkhateeb a écrit :
I'm not sure I understand the outcome from reading the JIRA and this
thread. What will happen exactly? Are you going to make groovy scripts
part of the call stack? Are you going to use @CompileStatic? Or are
you just going to move them to src/main/groovy?

On Fri, Sep 20, 2019 at 5:14 PM Jacques Le Roux
<jacques.le.r...@les7arts.com> wrote:
Thanks Paul, Gil, for your suggestions,

I have created OFBIZ-11205 for that

Jacques

Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :
Hi Devs,

While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I 
discussed with Mathieu and we had some ideas.

Mathieu suggested to move Groovy scripts from /groovyScripts/ 
to/src/main/groovy/.

I was initially reluctant because I love to be able to change things on the 
fly. That's why I liked Minilang and still like widgets, Freemarker
templates and Groovy Scripts.

We also know the advantages of compilation. But then I thought: why not have 
best of both Groovy worlds: compile and on the fly.

I tried and it works. So here is the (simple) plan:

1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
2. We add the necessary packages names
3. Devs can then open "gradlew --continuous" in a terminal and let it like 
that. It will continuously build on any changes in Gradle sourcesets

So, if you modify a Groovy scripts while running an OFBiz instance, the changes 
will be reflected in the instance and you can check possible syntax
or alike issues in the terminal running the continuous build. It's very fast 
since only changes have an impact on the build.

I'm sure there are other benefits to follow "the common convention of putting groovy 
compiled sources in ${COMPONENT}/src/main/groovy.", as
suggested Mathieu.

I see no disadvantages, do you? If nobody disagree with this idea, I'll create 
a Jira for that.

Feedback welcome, thanks

Jacques


Reply via email to