Hi Jacques, Dan,
I believe your positions are not that far apart.
Jacques suggested to create a 23.09 branch which would happen in
September 2023 and gives us 9 weeks from now. Dan suggested at least 4
weeks to stabilize trunk before creating the branch.
I agree with you both: let's
Let's see what others think ;)
Le 28/07/2023 à 17:47, Daniel Watford a écrit :
Hi Jacques,
I would like to see a delay of at least 4 weeks to give interested parties
a chance to exercise the parts of OFBiz they are most familiar with.
I'm happy to be challenged on this, though. Choosing a
I'm actually routinely backporting fixes to both branches (18 and 22).
Most of the time it's easy, but with moved groovy files it will be really more
work.
Le 28/07/2023 à 17:53, Daniel Watford a écrit :
I'm not familiar with that bug, but I am of the opinion that branch 22.01
is abandoned,
I'm not familiar with that bug, but I am of the opinion that branch 22.01
is abandoned, therefore there is no target branch to backport a bug to.
We also are not accepting bug fixes into the 18 branch - Perhaps this is a
decision we should reconsidered since it means we have no path to migrate
Hi Jacques,
I would like to see a delay of at least 4 weeks to give interested parties
a chance to exercise the parts of OFBiz they are most familiar with.
I'm happy to be challenged on this, though. Choosing a reasonable amount of
time is a balance between duplicating work when resources are
Also please consider these comments: https://s.apache.org/fcpi3
Le 28/07/2023 à 17:32, Jacques Le Roux a écrit :
Hi Daniel,
Ho many time do you think we need?
Maybe a month is indeed short. Though actually the changes are pretty simple
and we should not cross much issues
Le 28/07/2023 à
Hi Daniel,
Ho many time do you think we need?
Maybe a month is indeed short. Though actually the changes are pretty simple
and we should not cross much issues
Le 28/07/2023 à 17:17, Daniel Watford a écrit :
Hi Jacques,
Apologies if I've misunderstood your meaning, but I don't think we
Hi Jacques,
Apologies if I've misunderstood your meaning, but I don't think we should
rush to create a 23.xx branch.
Following such a large refactor, we are likely to find issues in our use of
groovy scripts over the coming weeks. If we go ahead and create a new 23.xx
branch from trunk too soon
Le 03/05/2023 à 09:45, Jacopo Cappellato a écrit :
On Tue, May 2, 2023 at 9:17 AM Daniel Watford wrote:
[...]
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
Hi,
I assume gradle "test" uses JUNIT which lack an ofbiz enviroment. Any
tests using variables relying on it will fail.
In trunk gradle „test“ consists of 293 tests of which only 22 are groovy
tests. These groovy tests do not rely on an ofbiz environment. After
this restructuring gradle
Hi,
I am working on the restructuring of the Groovy scripts. So far, I have
written a script that moves all Groovy files to the 'src' directory and
changes the references. In the second step, a package declaration is
added for all Groovy scripts. Prior to running my script, I did some
manual
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,
Hi everyone,
for the restructuring concerning the Groovy classes I have thought about
a few more things and have worked out a rough plan for a script/ Steps
to be done.
If there are no objections here I would start with the implementation of
such a script.
The idea from Gil Portenseigne to
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
Hi everyone, to minimize the potential for errors, I would like to see
if it is possible to write a script that moves the groovy files and
references in the first step and adds the package declaration for the
Groovy files in a second step.
If the general consensus is that we do this
+1
Thanks,
Gil
Le 03/05/2023 à 16:39, Michael Brohl a écrit :
+1 from my side.
Best regards,
Michael
Am 03.05.23 um 09:45 schrieb Jacopo Cappellato:
On Tue, May 2, 2023 at 9:17 AM Daniel Watford wrote:
[...]
I'll ask one more question (and then run for cover!): Rather than
carry out
+1 from my side.
Best regards,
Michael
Am 03.05.23 um 09:45 schrieb Jacopo Cappellato:
On Tue, May 2, 2023 at 9:17 AM Daniel Watford wrote:
[...]
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
Le 03/05/2023 à 09:45, Jacopo Cappellato a écrit :
On Tue, May 2, 2023 at 9:17 AM Daniel Watford wrote:
[...]
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
On Tue, May 2, 2023 at 9:17 AM Daniel Watford wrote:
[...]
> 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?
>
Yes, we could
Le 02/05/2023 à 09:16, Daniel Watford a écrit :
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?
That looks like an excellent
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
Hi Daniel,
Thanks for the code confirmation.
Yes I can confirm it works fine for me in Win7, Eclipse 2023-03 and JDK 17.
You can add a line above a breakpoint and all works as expected.
On the other hand, it work as if it was Java in a Virtual Box.
At least for me in VB 7, Ubuntu 20.04,
Hi Jacques,
Sorry for the late reply - it has been a busy May-day bank holiday weekend
here in the UK.
I think you have already checked this, but yes, you can indeed modify
Groovy script code while OFBiz is running. The script will be re-loaded
(and internally recompiled) by
Actually it's simpler now, even on Windows. You don't need to run "gradlew
--continuous".
By curiosity, I tried to stop at CommunicationEventServices.groovy[489] with the complete (not Eclipse accepted) package name instead of
communication, nothing happened.
While still running in debug
I can answer my question by my own. What is described at
https://markmail.org/message/2grqu63yvfpvxzz6:
/<>/
no longer works with Win7 (and also old *nix versions)? You now need to set a
property:
Hi Daniel,
Do you know how are reacting dynamically changed Groovy scripts while you are
Debugging them, at least in Eclipse (I don't use Intellij).
The big advantage of minilang was its faculty to allow dynamic changes, like
Freemarker does. We have the same advantage with Groovy.
But I
Hi All,
This is a convoluted matter.
If we can't get a consensus (changing source files locations is often "risky" and could introduce side effects as Daniel mentioned), simply adding
packages seems OK at 1st glance.
But, as Wiebke mentioned at OFBIZ-12813*, there is major issue if we get
Hello Wiebke,
Please could you confirm that this work only relates to groovy code that is
expected to be compiled to class files and will not alter the structure of
the various groovyScripts directories in OFBiz components?
The reason for checking is that groovyScripts are loaded as independent
Hi everyone,
I have created OFBIZ-12813 to coordinate the refactoring work.
Best regards,
Wiebke
Am 27.04.23 um 19:18 schrieb Jacques Le Roux:
Hi Michael,
Actually, as you may have seen with recent Daniel's work, lazy
consensus is de facto if nobody oppose :)
Cheers
Jacques
Le
Hi Michael,
Actually, as you may have seen with recent Daniel's work, lazy consensus is de
facto if nobody oppose :)
Cheers
Jacques
Le 27/04/2023 à 18:49, Michael Brohl a écrit :
Hi everyone,
what do you think about this refactoring suggestion?
We would organize to do this work but won't
Hi everyone,
what do you think about this refactoring suggestion?
We would organize to do this work but won't start until the community
decides to do so. It will be some amount of work so it should definetely
be backed by the community.
Can we apply lazy consensus here or do we need some
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
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
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
We have a working solution with all tests passing for release22.01 and
trunk, I have created a Jira issue to track the effort.
https://issues.apache.org/jira/browse/OFBIZ-12808
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 19.04.23 um 15:52 schrieb Michael Brohl:
Hi
Hi Michael,
That's surely the best and cleaner solution
Thanks
Jacques
Le 19/04/2023 à 15:52, Michael Brohl a écrit :
Hi everyone,
it seems that we have a solution for the Eclipse Java build and runtime
problems we faced with JDK 17 (not speaking of the Groovy build problems).
We removed
Hi everyone,
it seems that we have a solution for the Eclipse Java build and runtime
problems we faced with JDK 17 (not speaking of the Groovy build problems).
We removed some (transitive) dependencies in the build file and updated
some of them so that libraries are used from the JDK instead
Hi All,
Again, sorry for the flood. I don't know what happened.
I finally received all the related messages "from the ML" between 17h00 and
17h40.
Luckily, I'm seing the image attached at
https://lists.apache.org/thread/yxmdxy81ywwhldg8ml4foqls5df0hy8s:
https://s.apache.org/zw3b8
So it
Le 15/04/2023 à 08:56, Jacques Le Roux a écrit :
Le 14/04/2023 à 21:53, Michael Brohl a écrit :
Additionally, I realized that the settings file is (re)generated by the Gradle eclipse task and the property vanished during the process. It would
be necessary to add the setting during the build.
Sorry for the flood, I have never seen a such thing on this ML
Le 17/04/2023 à 16:21, Jacques Le Roux a écrit :
Le 15/04/2023 à 08:56, Jacques Le Roux a écrit :
Le 14/04/2023 à 21:53, Michael Brohl a écrit :
Additionally, I realized that the settings file is (re)generated by the Gradle eclipse
Hi Michael,
Thank you for the heads up.
I was aware that JetBrains provided licenses for open source committers,
but thought I was ineligible on account of my consultancy work.
However, your message prompted me to go and re-read the terms and
conditions and I now realise that I am eligible to
Le 15/04/2023 à 08:56, Jacques Le Roux a écrit :
Le 14/04/2023 à 21:53, Michael Brohl a écrit :
Additionally, I realized that the settings file is (re)generated by the Gradle eclipse task and the property vanished during the process. It would
be necessary to add the setting during the build.
Le 15/04/2023 à 08:56, Jacques Le Roux a écrit :
Le 14/04/2023 à 21:53, Michael Brohl a écrit :
Additionally, I realized that the settings file is (re)generated by the Gradle eclipse task and the property vanished during the process. It would
be necessary to add the setting during the build.
This forwarded message did not pass I guess because I put an image I now removed
Message transféré
Sujet : Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging
environment.
Date : Mon, 17 Apr 2023 12:11:28 +0200
De :Jacques Le Roux
Pour : dev
Le 14/04/2023 à 21:53, Michael Brohl a écrit :
Additionally, I realized that the settings file is (re)generated by the Gradle eclipse task and the property vanished during the process. It would
be necessary to add the setting during the build.
Yes, as I could not get it working, I did not dig
Thanks Jacques!
for me, org.eclipse.jdt.core.compiler.ignoreUnnamedModuleForSplitPackage
only works as far as the build problems get away but there are still
packages and classes not found by Eclipse at runtime so not really
working for debugging here.
Additionally, I realized that the
Hi Daniel,
thanks for your reply!
Are you aware that you can get a free license being an Open Source
Commiter at the ASF? See
https://www.jetbrains.com/community/opensource/#support .
I have OFBiz up and running with IntelliJ Idea which works flawlessly
but we are mainly using Eclipse for
Hi Michael,
I did try getting Eclipse up and running a few weeks ago for OFBiz but
failed, unfortunately.
Following up from Jacques, I think Groovy debugging is going to be a really
important feature for an OFBiz Developers' IDE since so much of our
minilang is getting converted to Groovy
Hi Michael,
Yes I did some. I have still this issue* pending but it does not prevent to
debug.
It's also a long time I'm not able to make breakpoints to work for groovy.
I must say I did not dig much because most of the time (so far all cases) a
printl is enough.
*
Hi devs,
just to pull up this topic to get more attention:
is there anyone out there who has successfully imported a JDK 17 based
Apache OFBiz project into Eclipse and debugged from there?
Thanks and regards,
Michael
Am 16.02.23 um 17:59 schrieb Jacques Le Roux:
Hi,
It's a complicated
Hi Cheng Hu Shan,
Thanks the tip about <> did not work for me. I
wonder why. I also tried ENABLED and enabled
Jacques
Le 17/02/2023 à 11:39, Cheng Hu Shan a écrit :
Hi,
thank you for these links. The first one provided a working temporary solution. Copying that line into settings (and
Hi,
thank you for these links. The first one provided a working temporary
solution. Copying that line into settings (and changing "enable" to
lowercase) has at least hidden the amount of errors.
I came across this blog post:
Hello,
Many thanks for your helpful answers.
Carlos
El jue, 16 feb 2023 a las 14:01, Jacques Le Roux (<
jacques.le.r...@les7arts.com>) escribió:
> Hi,
>
> It's a complicated matter due to indecision in an OpenJDK.
>
> I'm curious to know if people using Intellij are crossing the same issue?
>
Hi,
It's a complicated matter due to indecision in an OpenJDK.
I'm curious to know if people using Intellij are crossing the same issue? That could explain why it has not been reported. Most OFBiz committers are
using Intellij, I guess.
I looked at this issue some time ago and found that
Hi,
I've encounterd the same problem. I cannot offer a solution. But maybe a
better description of this problem may help you.
The root problem seems to be how the Java Platform Modular System
introduced in version 9 and foreign libraries interact: Since Java 9 one
particular package may
Hello Community,
Hope you're all doing well.
I'm trying to setup OFBiz 22 and Eclipse in order to get a debugging
environment following
https://cwiki.apache.org/confluence/display/ofbiz/eclipse+tips
OFBiz version: 22.01
JDK: 17
Eclipse: Eclipse IDE for Enterprise Java and Web Developers
56 matches
Mail list logo
