Hi Samuel,
For the moment I don't expect to change "`commponent://` url in xml (screen,
service,...)", but that a good idea!
I suggest you create a Jira for that
Thanks
Jacques
Le 23/09/2019 à 10:31, Samuel a écrit :
Hello Jacques,
I think it is a really good idea: add more checks on our code!
The option to use `gradlew --continous classes` make me think about putting
more things into jar (but this another discussion )
I still have one question: what about `commponent://` url in xml (screen, service,...) ? are you going to rewrite ComponentLocationResolver to load
groovy from compiled `.class`
Samuel
On 16/09/2019 12:28, Jacques Le Roux wrote:
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
