Hello Wiebke,
The dev mentioned in the last email is now done and available in the
last idea plugin version with 2023.1 Intellij community version.
You can find all the installation instructions here :
https://github.com/Nereide-lab/idea-ofbiz-plugin#usage
I hope this helps.
Best regards,
Gaetan
On 05/05/2023 16:43, Gil Portenseigne wrote:
Hello,
Reading this i discussed with Gaëtan about somthing that could help control
that every groovyScript reference in Screens/Forms/Services are effectively
referencing an existing file.
As you might know, Gaëtan is contributing an IDEA plugin dedicated to OFBiz [1].
The plugin already manage component:// notation, that allow highlighting of
missing referenced file in editor.
We discussed about inspection feature, that could detect bad references for
groovyScript (and others) files. Whereas he is not familiar with IDEA
inspection feature in the plugin, we could try to start building one for this
particular effort, if that could bring more confidence in migration.
Regards,
Gil
[1] https://lists.apache.org/thread/03fr40tvhkv97pqrgt4nl78w4m6ml33w
On 2023/05/02 07:16:35 Daniel Watford wrote:
Hi Michael,
I would be concerned about our capacity to move all these groovy scripts
and ensure correct location updates are made to the elements in the controller.xml files and elements in service definitions in
both trunk and the release22.01 branch.
If we were to pursue these changes, could we add a test mode to code that
parses service definitions and controller xml files to check that the
groovy location (and invoked methods were relevant) are accessible? This
means we would have some automation to help ensure changes have been
applied correctly.
This will be a big undertaking, so I would suggest creating some
mini-project-management similar to that done for the CodeNarc integration
where we have a list of files that need moving and committers add their
name to files they are actively working on. I would also request that we
introduce rules for this mini-project such as, 'No functional changes to
code', and 'keep Pull Requests small', etc.
To answer your original question, if we do not make the proposed changes to
release 22.01, we will substantially degrade the ability for developers
using Eclipse to work with OFBiz. But if we do proceed with this work, we
will effectively need to do it twice - once for the release22.01 branch and
once for trunk - a pretty heavy undertaking.
On balance I think it would be bad for the project to release OFBiz in a
state which is difficult for developers/system integrators to work with, so
we MUST ensure OFBiz is 'debuggable'.
I'll ask one more question (and then run for cover!): Rather than carry out
this work twice. What if we abandon the 22.01 release and instead make a
new release branch (23.xx) soon after moving the Groovy sources?
Thanks,
Dan.
On Wed, 26 Apr 2023 at 12:23, Michael Brohl
wrote:
Hi,
I suggest to start with a new ticket to coordinate the refactoring work
(will you take this into your hands, Wiebke?).
OFBIZ-10226 has another intention which will not solve the overall
problem Wiebke described.
Does the community agree that we'll have to do this work?
Even more, do we agree that it has to be done before we can ship a first
22.01 release based on JDK 17?
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 25.04.23 um 18:30 schrieb Jacques Le Roux:
Thanks Wiebke,
I know that for a while (https://s.apache.org/kewrn) but was
desperately trying to avoid what you propose. It's indeed the right
solution.
So I think we can go on with OFBIZ-10226. At the bottom there is a
link to a related discussion with some opinions from then. Or do you
prefer to start anew for the sake of clarity?
Thanks again for your work, I was not aware of this Groovy page. It
definitely confirms what Mathieu said then.
Jacques
Le 25/04/2023 à 16:09, Wiebke Pätzold a écrit :
Hi everyone,
I did a bit of research regarding the groovy debugging.
After some research I found this:
“The Java Platform Module System requires that classes in distinct
modules have distinct package names. Groovy has its own "modules" but
these haven’t historically been structured according to the above
requirement. For this reason, Groovy 2.x and 3.0 should be added to
the classpath not module path when using JDK9+. This places Groovy’s
classes into the unnamed module where the split package naming
requirement is not enforced.“
http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages
For testing I used the service "sendEmailDated" in
CommunicationEventServices.groovy. I can confirm the described
behavior of Jacques, without a package declaration the service does
not stop at my breakpoint. If I add the package declaration for the
class, the service stops at my breakpoint.
From my point of view it would make sense for the project not only to
add the package declaration in all groovy
