Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

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 stabilize trunk in the next weeks with the 
goal to create a 23.09 branch. If we see that it will rather be 23.10, 
should be no problem.


I am working on the plugins and remaining framework issues. Wiebke has 
provided the scripts before going on vacation which are already prepared 
for plugins as well so I am confident that we will have a good 
foundation soon.


Thanks and regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 28.07.23 um 19:16 schrieb Jacques Le Roux:

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 reasonable 
amount of
time is a balance between duplicating work when resources are 
limited, and

moving the project forward. I don't think there is an obvious answer to
this one, so the maintainers will need to propose the branch when 
they feel

the time is right.

Although not expected to be the case, if we were to find lots of issues,
then we could delay creating the 23.xx branch accordingly.

On Fri, 28 Jul 2023 at 16:32, Jacques Le Roux 


wrote:


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 
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 we will have to fix those groovy script 
issues

in trunk and the new branch - increasing the amount of work needed.

I agree that we want to get a 23.xx branch in place once we are happy

that
the groovy script refactor work has completed and had a chance to 
have a

few fixes applied.

Thanks,

Dan.

On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


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 after moving the Groovy sources?

Yes, we could do this. Abandon 22.01, perform the refactoring, 
create

a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Hi,

In relation with [OFBIZ-12813] Refactor groovy folder structure 
and add

package declaration

As soon as a groovy file is modified, and especially moved, in trunk
(framework is done, plugins is waiting), it will be more hand work to
backport.
So I think we should indeed quickly think about creating a 23.xx

(23.09?)

release branch. Else if will be soon a nightmare to backport fixes.

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 reasonable amount of
time is a balance between duplicating work when resources are limited, and
moving the project forward. I don't think there is an obvious answer to
this one, so the maintainers will need to propose the branch when they feel
the time is right.

Although not expected to be the case, if we were to find lots of issues,
then we could delay creating the 23.xx branch accordingly.

On Fri, 28 Jul 2023 at 16:32, Jacques Le Roux 
wrote:


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 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 we will have to fix those groovy script issues
in trunk and the new branch - increasing the amount of work needed.

I agree that we want to get a 23.xx branch in place once we are happy

that

the groovy script refactor work has completed and had a chance to have a
few fixes applied.

Thanks,

Dan.

On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


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 after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Hi,

In relation with [OFBIZ-12813] Refactor groovy folder structure and add
package declaration

As soon as a groovy file is modified, and especially moved, in trunk
(framework is done, plugins is waiting), it will be more hand work to
backport.
So I think we should indeed quickly think about creating a 23.xx

(23.09?)

release branch. Else if will be soon a nightmare to backport fixes.

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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, 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
users towards a fix in case of a serious bug. But once again, I am mindful
that we have limited time to do additional work - perhaps this is a subject
for a different thread.



On Fri, 28 Jul 2023 at 16:46, Jacques Le Roux 
wrote:


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 à 17:17, Daniel Watford a écrit :

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 we will have to fix those groovy script

issues

in trunk and the new branch - increasing the amount of work needed.

I agree that we want to get a 23.xx branch in place once we are happy

that

the groovy script refactor work has completed and had a chance to have a
few fixes applied.

Thanks,

Dan.

On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


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 after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Hi,

In relation with [OFBIZ-12813] Refactor groovy folder structure and add
package declaration

As soon as a groovy file is modified, and especially moved, in trunk
(framework is done, plugins is waiting), it will be more hand work to
backport.
So I think we should indeed quickly think about creating a 23.xx

(23.09?)

release branch. Else if will be soon a nightmare to backport fixes.

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Daniel Watford]

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
users towards a fix in case of a serious bug. But once again, I am mindful
that we have limited time to do additional work - perhaps this is a subject
for a different thread.



On Fri, 28 Jul 2023 at 16:46, Jacques Le Roux 
wrote:

> 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 à 17:17, Daniel Watford a écrit :
> >> 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 we will have to fix those groovy script
> issues
> >> in trunk and the new branch - increasing the amount of work needed.
> >>
> >> I agree that we want to get a 23.xx branch in place once we are happy
> that
> >> the groovy script refactor work has completed and had a chance to have a
> >> few fixes applied.
> >>
> >> Thanks,
> >>
> >> Dan.
> >>
> >> On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux <
> jacques.le.r...@les7arts.com>
> >> wrote:
> >>
> >>> 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 after moving the Groovy sources?
> >
>  Yes, we could do this. Abandon 22.01, perform the refactoring, create
>  a new release branch, stabilize (we could consider a shorter
>  stabilization period).
>  We could also extend our support (mostly for security vulnerability
>  fixes) to 18.12, at least until 1 or 2 releases have been published
>  out of the new branch.
> 
>  Jacopo
> >>> Hi,
> >>>
> >>> In relation with [OFBIZ-12813] Refactor groovy folder structure and add
> >>> package declaration
> >>>
> >>> As soon as a groovy file is modified, and especially moved, in trunk
> >>> (framework is done, plugins is waiting), it will be more hand work to
> >>> backport.
> >>> So I think we should indeed quickly think about creating a 23.xx
> (23.09?)
> >>> release branch. Else if will be soon a nightmare to backport fixes.
> >>>
> >>> Jacques
> >>>
> >>>
> >>>
>


-- 
Daniel Watford

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Daniel Watford]

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 limited, and
moving the project forward. I don't think there is an obvious answer to
this one, so the maintainers will need to propose the branch when they feel
the time is right.

Although not expected to be the case, if we were to find lots of issues,
then we could delay creating the 23.xx branch accordingly.

On Fri, 28 Jul 2023 at 16:32, Jacques Le Roux 
wrote:

> 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 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 we will have to fix those groovy script issues
> > in trunk and the new branch - increasing the amount of work needed.
> >
> > I agree that we want to get a 23.xx branch in place once we are happy
> that
> > the groovy script refactor work has completed and had a chance to have a
> > few fixes applied.
> >
> > Thanks,
> >
> > Dan.
> >
> > On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux <
> jacques.le.r...@les7arts.com>
> > wrote:
> >
> >> 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 after moving the Groovy sources?
> 
> >>> Yes, we could do this. Abandon 22.01, perform the refactoring, create
> >>> a new release branch, stabilize (we could consider a shorter
> >>> stabilization period).
> >>> We could also extend our support (mostly for security vulnerability
> >>> fixes) to 18.12, at least until 1 or 2 releases have been published
> >>> out of the new branch.
> >>>
> >>> Jacopo
> >> Hi,
> >>
> >> In relation with [OFBIZ-12813] Refactor groovy folder structure and add
> >> package declaration
> >>
> >> As soon as a groovy file is modified, and especially moved, in trunk
> >> (framework is done, plugins is waiting), it will be more hand work to
> >> backport.
> >> So I think we should indeed quickly think about creating a 23.xx
> (23.09?)
> >> release branch. Else if will be soon a nightmare to backport fixes.
> >>
> >> Jacques
> >>
> >>
> >>
>


-- 
Daniel Watford

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 à 17:17, Daniel Watford a écrit :

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 we will have to fix those groovy script issues
in trunk and the new branch - increasing the amount of work needed.

I agree that we want to get a 23.xx branch in place once we are happy that
the groovy script refactor work has completed and had a chance to have a
few fixes applied.

Thanks,

Dan.

On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux 
wrote:


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 after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Hi,

In relation with [OFBIZ-12813] Refactor groovy folder structure and add
package declaration

As soon as a groovy file is modified, and especially moved, in trunk
(framework is done, plugins is waiting), it will be more hand work to
backport.
So I think we should indeed quickly think about creating a 23.xx (23.09?)
release branch. Else if will be soon a nightmare to backport fixes.

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 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 we will have to fix those groovy script issues
in trunk and the new branch - increasing the amount of work needed.

I agree that we want to get a 23.xx branch in place once we are happy that
the groovy script refactor work has completed and had a chance to have a
few fixes applied.

Thanks,

Dan.

On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux 
wrote:


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 after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Hi,

In relation with [OFBIZ-12813] Refactor groovy folder structure and add
package declaration

As soon as a groovy file is modified, and especially moved, in trunk
(framework is done, plugins is waiting), it will be more hand work to
backport.
So I think we should indeed quickly think about creating a 23.xx (23.09?)
release branch. Else if will be soon a nightmare to backport fixes.

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Daniel Watford]

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 we will have to fix those groovy script issues
in trunk and the new branch - increasing the amount of work needed.

I agree that we want to get a 23.xx branch in place once we are happy that
the groovy script refactor work has completed and had a chance to have a
few fixes applied.

Thanks,

Dan.

On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux 
wrote:

> 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 after moving the Groovy sources?
> >>
> > Yes, we could do this. Abandon 22.01, perform the refactoring, create
> > a new release branch, stabilize (we could consider a shorter
> > stabilization period).
> > We could also extend our support (mostly for security vulnerability
> > fixes) to 18.12, at least until 1 or 2 releases have been published
> > out of the new branch.
> >
> > Jacopo
>
> Hi,
>
> In relation with [OFBIZ-12813] Refactor groovy folder structure and add
> package declaration
>
> As soon as a groovy file is modified, and especially moved, in trunk
> (framework is done, plugins is waiting), it will be more hand work to
> backport.
> So I think we should indeed quickly think about creating a 23.xx (23.09?)
> release branch. Else if will be soon a nightmare to backport fixes.
>
> Jacques
>
>
>

-- 
Daniel Watford

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo


Hi,

In relation with [OFBIZ-12813] Refactor groovy folder structure and add package 
declaration

As soon as a groovy file is modified, and especially moved, in trunk (framework 
is done, plugins is waiting), it will be more hand work to backport.
So I think we should indeed quickly think about creating a 23.xx (23.09?) 
release branch. Else if will be soon a nightmare to backport fixes.

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Cheng Hu Shan]

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 “test” finds over 500 tests. These surplus 
tests are meant for integration tests and do rely on an ofbiz environment.


I propose to change how the source set is created for a gradle “test” in 
build.gradle. Currently the source set includes all groovy test classes 
in src/test/groovy. Instead each individual groovy class that are 
supposed to be tested by this test should be added individually. 
Currently there are only 3 classes.


I added this change to the pull request. I’m open for feedback and 
alternative ideas.


Best regards,

Cheng Hu

Am 07.07.23 um 15:41 schrieb Wiebke Pätzold:

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 work such as moving imports under the 
license header and renaming Groovy scripts to avoid duplicated classes.


At this point, I am encountering some trouble with the build. When I 
run './gradlew test', it doesn't work because some variables (e.g. 
delegator, dispatcher, security) are not available. I set a breakpoint 
in SimpleTests.groovy's testDelegator() function, and when I run the 
testIntegration, the delegator is not null. However, when I run the 
'test' task, the delegator is null.


Does anyone have an idea why I am getting null for the delegator in 
test (build)?


I have created a pull request in OFBIZ-12813, so if anybody wants to 
test it, feel free to do so.


Best regards,

Wiebke


Am 12.05.23 um 12:13 schrieb Wiebke Pätzold:

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 implement a inspection feature as a 
plugin to detect bad references could be a nice feature to check if 
the restructuring was successful.


Steps for the restructuring:

1st step:
* move all groovy test files to 
{basedir}/src/test/groovy/org/apache/ofbiz/*

* bevore moving add file to list of moved files
* work throu the list of moved files and adjust references (should be 
under {basedir}/testdef/*)



2nd step (services and frontend scripts) :
* move the remaining groovy files to 
{basedir}/src/main/groovy/org/apache/ofbiz/*/*.groovy

* bevore moving add file to list of moved files
* adjust references
** Work through the list of files moved and search for occurrences in 
other files and adapt import * for frontend scripts, adapt the 
location for services in the service definition.


3rd step:
* add package if none exists in groovy file yet

4th step:
* check moved files lists to see if this is a proper package 
declaration (Has to be done manually)



Best regards,
Wiebke



Am 05.05.23 um 15:52 schrieb Wiebke Pätzold:
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 restructuring  for the 
trunk, then I would deal next week with how such a script has to 
look like and to which degree the restructuring can be done 
automatically. Best regards, Wiebke


Am 02.05.23 um 09:16 schrieb Daniel Watford:

Hi Michael,

I would be concerned about our capacity to move all these groovy 
scripts
and ensure correct location updates are made to the type="groovy"

path="..." /> elements in the controller.xml files and engine="groovy" location="..." .../> 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 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Wiebke Pätzold]

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 work such as moving imports under the license header and renaming 
Groovy scripts to avoid duplicated classes.


At this point, I am encountering some trouble with the build. When I run 
'./gradlew test', it doesn't work because some variables (e.g. 
delegator, dispatcher, security) are not available. I set a breakpoint 
in SimpleTests.groovy's testDelegator() function, and when I run the 
testIntegration, the delegator is not null. However, when I run the 
'test' task, the delegator is null.


Does anyone have an idea why I am getting null for the delegator in test 
(build)?


I have created a pull request in OFBIZ-12813, so if anybody wants to 
test it, feel free to do so.


Best regards,

Wiebke


Am 12.05.23 um 12:13 schrieb Wiebke Pätzold:

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 implement a inspection feature as a 
plugin to detect bad references could be a nice feature to check if 
the restructuring was successful.


Steps for the restructuring:

1st step:
* move all groovy test files to 
{basedir}/src/test/groovy/org/apache/ofbiz/*

* bevore moving add file to list of moved files
* work throu the list of moved files and adjust references (should be 
under {basedir}/testdef/*)



2nd step (services and frontend scripts) :
* move the remaining groovy files to 
{basedir}/src/main/groovy/org/apache/ofbiz/*/*.groovy

* bevore moving add file to list of moved files
* adjust references
** Work through the list of files moved and search for occurrences in 
other files and adapt import * for frontend scripts, adapt the 
location for services in the service definition.


3rd step:
* add package if none exists in groovy file yet

4th step:
* check moved files lists to see if this is a proper package 
declaration (Has to be done manually)



Best regards,
Wiebke



Am 05.05.23 um 15:52 schrieb Wiebke Pätzold:
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 restructuring  for the 
trunk, then I would deal next week with how such a script has to look 
like and to which degree the restructuring can be done automatically. 
Best regards, Wiebke


Am 02.05.23 um 09:16 schrieb Daniel Watford:

Hi Michael,

I would be concerned about our capacity to move all these groovy 
scripts
and ensure correct location updates are made to the type="groovy"

path="..." /> 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 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Gaetan]

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 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Wiebke Pätzold]

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 implement a inspection feature as a 
plugin to detect bad references could be a nice feature to check if the 
restructuring was successful.


Steps for the restructuring:

1st step:
* move all groovy test files to {basedir}/src/test/groovy/org/apache/ofbiz/*
* bevore moving add file to list of moved files
* work throu the list of moved files and adjust references (should be 
under {basedir}/testdef/*)



2nd step (services and frontend scripts) :
* move the remaining groovy files to 
{basedir}/src/main/groovy/org/apache/ofbiz/*/*.groovy

* bevore moving add file to list of moved files
* adjust references
** Work through the list of files moved and search for occurrences in 
other files and adapt import * for frontend scripts, adapt the location 
for services in the service definition.


3rd step:
* add package if none exists in groovy file yet

4th step:
* check moved files lists to see if this is a proper package declaration 
(Has to be done manually)



Best regards,
Wiebke



Am 05.05.23 um 15:52 schrieb Wiebke Pätzold:
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 restructuring  for the 
trunk, then I would deal next week with how such a script has to look 
like and to which degree the restructuring can be done automatically. 
Best regards, Wiebke


Am 02.05.23 um 09:16 schrieb Daniel Watford:

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, 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Gil Portenseigne]

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  path="..." /> elements in the controller.xml files and  engine="groovy" location="..." .../> 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 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Wiebke Pätzold]

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 restructuring  for the 
trunk, then I would deal next week with how such a script has to look 
like and to which degree the restructuring can be done automatically. 
Best regards, Wiebke


Am 02.05.23 um 09:16 schrieb Daniel Watford:

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 classes, but also to ensure
a consistent folder structure.

For example, under framework -> base -> src there is a distinction
between main and test. Within the test folder there is again a
distinction between groovy and Java.

Therefore I would suggest to introduce this structure everywhere,
which means that there would be a src folder which in turn contains
main, test, ... within these folders there is again a distinction
between groovy and java.

Example:
applications -> product -> src -> main -> groovy -> org -> apache ->
ofbiz ->...
-> java  -> org -> apache -> ofbiz ->...
   -> test -> groovy

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Gil Portenseigne]

+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
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 do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

+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 make a
new release branch (23.xx) soon after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo


Sounds fine to me

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[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 make a
> new release branch (23.xx) soon after moving the Groovy sources?
>

Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 idea to me

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Daniel Watford]

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 classes, but also to ensure
> >> a consistent folder structure.
> >>
> >> For example, under framework -> base -> src there is a distinction
> >> between main and test. Within the test folder there is again a
> >> distinction between groovy and Java.
> >>
> >> Therefore I would suggest to introduce this structure everywhere,
> >> which means that there would be a src folder which in turn contains
> >> main, test, ... within these folders there is again a distinction
> >> between groovy and java.
> >>
> >> Example:
> >> applications -> product -> src -> main -> groovy -> org -> apache ->
> >> ofbiz ->...
> >> -> java  -> org -> apache -> ofbiz ->...
> >>   -> test -> groovy
> >> -> org -> apache -> ofbiz ->...
> >> -> java  -> org -> apache -> ofbiz ->...
> >>
> >>
> >> What do you think about this idea?
> >>
> >> Best regards,
> >> Wiebke
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >>
> >> Am 20.04.23 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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, Eclipse 2023-03 and JDK 17.
That means that Eclipse asks you if you want deconnect, continue (at your own 
risk), etc.
And Eclipse tells you that it's specific to the VM context.

Jacques

Le 02/05/2023 à 08:55, Daniel Watford a écrit :

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 GroovyUtil#getScriptClassFromLocation.

Although at first glance it appears that GroovyUtil has a PARSED_SCRIPTS
cache, so I'm not sure why the updated script is loaded. Perhaps some other
process is running to invalidate the cache on file update.

I have not delved into the details of how IntelliJ maps loaded classes to
source files. I assume there is a mechanism that detects the loading of new
classes and figures out a mapping of class back to source file, meaning
that once a groovy script is loaded, all breakpoints in that script's
source file become live while debugging and will move appropriately
following source code changes.

Dan.

On Sat, 29 Apr 2023 at 13:12, Jacques Le Roux 
wrote:


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 wonder for dynamically changed Groovy scripts while you are
Debugging in Eclipse.
For instance for Java it's sometimes allowed, but sometimes you need to
reload all :/

Jacques

Le 28/04/2023 à 12:30, Daniel Watford a écrit :

The reason for checking is that groovyScripts are loaded as independent
scripts and compiled at runtime by OFBiz (See
GroovyUtil#getScriptClassFromLocation), rather than being loaded from a
pre-compiled JAR.

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Daniel Watford]

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 GroovyUtil#getScriptClassFromLocation.

Although at first glance it appears that GroovyUtil has a PARSED_SCRIPTS
cache, so I'm not sure why the updated script is loaded. Perhaps some other
process is running to invalidate the cache on file update.

I have not delved into the details of how IntelliJ maps loaded classes to
source files. I assume there is a mechanism that detects the loading of new
classes and figures out a mapping of class back to source file, meaning
that once a groovy script is loaded, all breakpoints in that script's
source file become live while debugging and will move appropriately
following source code changes.

Dan.

On Sat, 29 Apr 2023 at 13:12, Jacques Le Roux 
wrote:

> 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 wonder for dynamically changed Groovy scripts while you are
> Debugging in Eclipse.
> For instance for Java it's sometimes allowed, but sometimes you need to
> reload all :/
>
> Jacques
>
> Le 28/04/2023 à 12:30, Daniel Watford a écrit :
> > The reason for checking is that groovyScripts are loaded as independent
> > scripts and compiled at runtime by OFBiz (See
> > GroovyUtil#getScriptClassFromLocation), rather than being loaded from a
> > pre-compiled JAR.
>


-- 
Daniel Watford

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 mode, I just changed the package name to 
communication, the breakpoint worked :)
So Eclipse interprets dynamic Groovy changes, as it was in the past with "gradlew --continuous". I don't think the location is a problem as long as 
Eclipse accepts the package name.



HTH


Le 30/04/2023 à 18:52, Jacques Le Roux a écrit :

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:
https://stackoverflow.com/questions/62674182/how-can-i-enable-gradle-file-system-watching-persistently

I'll try that on Ubuntu 20.04 and Eclipse 23.03

Jacques


Le 29/04/2023 à 14:10, Jacques Le Roux a écrit :

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 wonder for dynamically changed Groovy scripts while you are Debugging in 
Eclipse.
For instance for Java it's sometimes allowed, but sometimes you need to reload 
all :/

Jacques

Le 28/04/2023 à 12:30, Daniel Watford a écrit :

The reason for checking is that groovyScripts are loaded as independent
scripts and compiled at runtime by OFBiz (See
GroovyUtil#getScriptClassFromLocation), rather than being loaded from a
pre-compiled JAR.

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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:
https://stackoverflow.com/questions/62674182/how-can-i-enable-gradle-file-system-watching-persistently

I'll try that on Ubuntu 20.04 and Eclipse 23.03

Jacques


Le 29/04/2023 à 14:10, Jacques Le Roux a écrit :

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 wonder for dynamically changed Groovy scripts while you are Debugging in 
Eclipse.
For instance for Java it's sometimes allowed, but sometimes you need to reload 
all :/

Jacques

Le 28/04/2023 à 12:30, Daniel Watford a écrit :

The reason for checking is that groovyScripts are loaded as independent
scripts and compiled at runtime by OFBiz (See
GroovyUtil#getScriptClassFromLocation), rather than being loaded from a
pre-compiled JAR.

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 wonder for dynamically changed Groovy scripts while you are Debugging in 
Eclipse.
For instance for Java it's sometimes allowed, but sometimes you need to reload 
all :/

Jacques

Le 28/04/2023 à 12:30, Daniel Watford a écrit :

The reason for checking is that groovyScripts are loaded as independent
scripts and compiled at runtime by OFBiz (See
GroovyUtil#getScriptClassFromLocation), rather than being loaded from a
pre-compiled JAR.

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 into 
this way.

At least in Eclipse, when you want to add a package name, eg in 
CommunicationEventServices.groovy, you think that adding

   package applications.party.groovyScripts.communication

should be OK. But Eclipse is not OK. It suggests to use only "communication" as 
package name. And then debugging indeed works.

I believe Wiebke somehow spoke of that that by referring to
http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages 
:


“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.“


In other words, I translate that by : adding "simple" packages names works for debugging as long as there is no Groovy package names collisions. Seems 
that we can't ensure that.


Jacques

* <>

Le 28/04/2023 à 12:30, Daniel Watford a écrit :

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
scripts and compiled at runtime by OFBiz (See
GroovyUtil#getScriptClassFromLocation), rather than being loaded from a
pre-compiled JAR.

OFBIZ-12149 (https://issues.apache.org/jira/browse/OFBIZ-12149) made
changes to the build to have those script files included from source set
but excluded from compilation. If those groovy script files are moved to
sit alongside groovy classes then we may need to rework OFBIZ-12149.

Thanks,

Dan.


On Fri, 28 Apr 2023 at 10:09, Wiebke Pätzold
wrote:


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 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 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 kind of voting?

Best regards,

Michael Brohl

ecomify GmbH -www.ecomify.de


Am 26.04.23 um 13:21 schrieb Michael Brohl:

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 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Daniel Watford]

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
scripts and compiled at runtime by OFBiz (See
GroovyUtil#getScriptClassFromLocation), rather than being loaded from a
pre-compiled JAR.

OFBIZ-12149 (https://issues.apache.org/jira/browse/OFBIZ-12149) made
changes to the build to have those script files included from source set
but excluded from compilation. If those groovy script files are moved to
sit alongside groovy classes then we may need to rework OFBIZ-12149.

Thanks,

Dan.


On Fri, 28 Apr 2023 at 10:09, Wiebke Pätzold 
wrote:

> 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 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 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 kind of voting?
> >>
> >> Best regards,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 26.04.23 um 13:21 schrieb Michael Brohl:
> >>> 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 classes, but also to
> > ensure a consistent folder structure.
> >
> > For example, under framework -> base -> src there is a distinction
> > between main and test. Within the test folder there is again a
> > distinction between groovy and Java.
> >
> > Therefore I would suggest to introduce this structure everywhere,
> > which means that there would be a src folder which in turn
> > contains main, test, ... within these folders there is again a
> > distinction between groovy and java.
> >
> > Example:
> > applications -> product -> src -> main -> groovy -> org -> apache
> > -> ofbiz ->...
> > -> java  -> org -> apache -> ofbiz ->...
> >   -> test ->
> > groovy -> org -> apache -> ofbiz ->...
> > -> java  -> org -> apache -> ofbiz ->...
> >
> >

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Wiebke Pätzold]

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 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 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 kind of voting?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 26.04.23 um 13:21 schrieb Michael Brohl:

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 classes, but also to 
ensure a consistent folder structure.


For example, under framework -> base -> src there is a distinction 
between main and test. Within the test folder there is again a 
distinction between groovy and Java.


Therefore I would suggest to introduce this structure everywhere, 
which means that there would be a src folder which in turn 
contains main, test, ... within these folders there is again a 
distinction between groovy and java.


Example:
applications -> product -> src -> main -> groovy -> org -> apache 
-> ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...
  -> test -> 
groovy -> org -> apache -> ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...


What do you think about this idea?

Best regards,
Wiebke

ecomify GmbH - www.ecomify.de



Am 20.04.23 um 11:46 schrieb Michael Brohl:
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 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 of external libaries. This avoids the compiler from 
finding duplicate classes which seem to be ignored and therefore 
not being found also at runtime.


We are checking the changes with a project now and provide a 
pull request when we are sure everything works fine.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

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 settings file is 
(re)generated by 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[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 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 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 kind of voting?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 26.04.23 um 13:21 schrieb Michael Brohl:

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 classes, but also to ensure a 
consistent folder structure.


For example, under framework -> base -> src there is a distinction between main and test. Within the test folder there is again a distinction 
between groovy and Java.


Therefore I would suggest to introduce this structure everywhere, which means that there would be a src folder which in turn contains main, test, 
... within these folders there is again a distinction between groovy and java.


Example:
applications -> product -> src -> main -> groovy -> org -> apache -> ofbiz ->...
-> java  -> org -> apache -> ofbiz ->...
  -> test -> groovy -> org -> apache 
-> ofbiz ->...
-> java  -> org -> apache -> ofbiz ->...


What do you think about this idea?

Best regards,
Wiebke

ecomify GmbH - www.ecomify.de



Am 20.04.23 um 11:46 schrieb Michael Brohl:

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 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 of 
external libaries. This avoids the compiler from finding duplicate classes which seem to be ignored and therefore not being found also at runtime.


We are checking the changes with a project now and provide a pull request when 
we are sure everything works fine.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

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 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.


All in all, some kind of showstopper using OFBiz 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

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 kind of voting?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 26.04.23 um 13:21 schrieb Michael Brohl:

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 classes, but also to 
ensure a consistent folder structure.


For example, under framework -> base -> src there is a distinction 
between main and test. Within the test folder there is again a 
distinction between groovy and Java.


Therefore I would suggest to introduce this structure everywhere, 
which means that there would be a src folder which in turn contains 
main, test, ... within these folders there is again a distinction 
between groovy and java.


Example:
applications -> product -> src -> main -> groovy -> org -> apache -> 
ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...
  -> test -> groovy 
-> org -> apache -> ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...


What do you think about this idea?

Best regards,
Wiebke

ecomify GmbH - www.ecomify.de



Am 20.04.23 um 11:46 schrieb Michael Brohl:
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 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 of external libaries. This avoids the compiler from 
finding duplicate classes which seem to be ignored and therefore 
not being found also at runtime.


We are checking the changes with a project now and provide a pull 
request when we are sure everything works fine.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

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 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.


All in all, some kind of showstopper using OFBiz with JDK 17 and 
Eclipse which has to be solved somehow.


Thanks,

Michael

Am 14.04.23 um 16:50 schrieb Jacques Le Roux:

Hi Michael,

Yes I did some. I 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

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 classes, but also to ensure 
a consistent folder structure.


For example, under framework -> base -> src there is a distinction 
between main and test. Within the test folder there is again a 
distinction between groovy and Java.


Therefore I would suggest to introduce this structure everywhere, 
which means that there would be a src folder which in turn contains 
main, test, ... within these folders there is again a distinction 
between groovy and java.


Example:
applications -> product -> src -> main -> groovy -> org -> apache -> 
ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...
  -> test -> groovy 
-> org -> apache -> ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...


What do you think about this idea?

Best regards,
Wiebke

ecomify GmbH - www.ecomify.de



Am 20.04.23 um 11:46 schrieb Michael Brohl:
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 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 of external libaries. This avoids the compiler from finding 
duplicate classes which seem to be ignored and therefore not being 
found also at runtime.


We are checking the changes with a project now and provide a pull 
request when we are sure everything works fine.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

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 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.


All in all, some kind of showstopper using OFBiz with JDK 17 and 
Eclipse which has to be solved somehow.


Thanks,

Michael

Am 14.04.23 um 16:50 schrieb Jacques Le Roux:

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.


* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

Hi devs,

just to pull up this topic to get more attention:

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[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 classes, but also to ensure a 
consistent folder structure.


For example, under framework -> base -> src there is a distinction between main and test. Within the test folder there is again a distinction 
between groovy and Java.


Therefore I would suggest to introduce this structure everywhere, which means that there would be a src folder which in turn contains main, test, 
... within these folders there is again a distinction between groovy and java.


Example:
applications -> product -> src -> main -> groovy -> org -> apache -> ofbiz ->...
-> java  -> org -> apache -> ofbiz ->...
  -> test -> groovy -> org -> apache 
-> ofbiz ->...
-> java  -> org -> apache -> ofbiz ->...


What do you think about this idea?

Best regards,
Wiebke

ecomify GmbH - www.ecomify.de



Am 20.04.23 um 11:46 schrieb Michael Brohl:

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 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 of external 
libaries. This avoids the compiler from finding duplicate classes which seem to be ignored and therefore not being found also at runtime.


We are checking the changes with a project now and provide a pull request when 
we are sure everything works fine.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

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 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.


All in all, some kind of showstopper using OFBiz with JDK 17 and Eclipse which 
has to be solved somehow.

Thanks,

Michael

Am 14.04.23 um 16:50 schrieb Jacques Le Roux:

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.

* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

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 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 Eclipse compiler (used by 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Wiebke Pätzold]

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 classes, but also to ensure a 
consistent folder structure.


For example, under framework -> base -> src there is a distinction 
between main and test. Within the test folder there is again a 
distinction between groovy and Java.


Therefore I would suggest to introduce this structure everywhere, which 
means that there would be a src folder which in turn contains main, 
test, ... within these folders there is again a distinction between 
groovy and java.


Example:
applications -> product -> src -> main -> groovy -> org -> apache -> 
ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...
  -> test -> groovy -> 
org -> apache -> ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...


What do you think about this idea?

Best regards,
Wiebke

ecomify GmbH - www.ecomify.de



Am 20.04.23 um 11:46 schrieb Michael Brohl:
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 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 
of external libaries. This avoids the compiler from finding duplicate 
classes which seem to be ignored and therefore not being found also 
at runtime.


We are checking the changes with a project now and provide a pull 
request when we are sure everything works fine.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

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 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.


All in all, some kind of showstopper using OFBiz with JDK 17 and 
Eclipse which has to be solved somehow.


Thanks,

Michael

Am 14.04.23 um 16:50 schrieb Jacques Le Roux:

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.


* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

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 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 Eclipse 
compiler (used by UI to build the project) is not using the same 
way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is 
operating properly thanks to the backwards compatibility of Java"


It's a "philosophy" difference. I found it well explained in this 
stackoverflow answer (and links from there): 
https://s.apache.org/8n6op


You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module


Anyway, 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

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 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 
of external libaries. This avoids the compiler from finding duplicate 
classes which seem to be ignored and therefore not being found also at 
runtime.


We are checking the changes with a project now and provide a pull 
request when we are sure everything works fine.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

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 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.


All in all, some kind of showstopper using OFBiz with JDK 17 and 
Eclipse which has to be solved somehow.


Thanks,

Michael

Am 14.04.23 um 16:50 schrieb Jacques Le Roux:

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.


* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

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 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 Eclipse 
compiler (used by UI to build the project) is not using the same 
way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is 
operating properly thanks to the backwards compatibility of Java"


It's a "philosophy" difference. I found it well explained in this 
stackoverflow answer (and links from there): 
https://s.apache.org/8n6op


You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module


Anyway, I need to fix that myself and will look at the best option 
when I'll get a chance. I tried some w/o success so far, . It's 
very annoying in Eclipse UI.
The best way could be to follow the point 7 at 
https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php 
I did not try yet, just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire 
project system, but if you import foreign libraries, they may 
bring their own version of a that package.


If you mouse over a faulty import statement in any of the java 
classes, you may find an error similiar to "The package [name] is 
accessible from more than one module:  java.xml". The 
 module refers to all foreign libraries stuffed into the 
classpath which counts as one huge unnamed module.


I'm surprised that this issue has not been reported yet, as it 
seems to be a fundamental one. My guess would be that we need to 
somehow update the build.gradle file.


On a side note: OfBiz actually starts and is operating properly 
thanks to the backwards compatiblity of Java, but the error 
messages remain.


Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 
(includes

Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 some (transitive) dependencies in the build file and updated some of them so that libraries are used from the JDK instead of external 
libaries. This avoids the compiler from finding duplicate classes which seem to be ignored and therefore not being found also at runtime.


We are checking the changes with a project now and provide a pull request when 
we are sure everything works fine.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

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 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.


All in all, some kind of showstopper using OFBiz with JDK 17 and Eclipse which 
has to be solved somehow.

Thanks,

Michael

Am 14.04.23 um 16:50 schrieb Jacques Le Roux:

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.

* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

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 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 Eclipse compiler (used by 
UI to build the project) is not using the same way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is operating properly 
thanks to the backwards compatibility of Java"

It's a "philosophy" difference. I found it well explained in this stackoverflow 
answer (and links from there): https://s.apache.org/8n6op

You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module

Anyway, I need to fix that myself and will look at the best option when I'll get a chance. I tried some w/o success so far, . It's very annoying 
in Eclipse UI.
The best way could be to follow the point 7 at https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php I did not try 
yet, just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire project system, but if you import foreign libraries, they may bring their own version of 
a that package.


If you mouse over a faulty import statement in any of the java classes, you may find an error similiar to "The package [name] is accessible 
from more than one module:  java.xml". The  module refers to all foreign libraries stuffed into the classpath which counts as 
one huge unnamed module.


I'm surprised that this issue has not been reported yet, as it seems to be a fundamental one. My guess would be that we need to somehow update 
the build.gradle file.


On a side note: OfBiz actually starts and is operating properly thanks to the 
backwards compatiblity of Java, but the error messages remain.

Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project, there
are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

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 of external 
libaries. This avoids the compiler from finding duplicate classes which 
seem to be ignored and therefore not being found also at runtime.


We are checking the changes with a project now and provide a pull 
request when we are sure everything works fine.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

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 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.


All in all, some kind of showstopper using OFBiz with JDK 17 and 
Eclipse which has to be solved somehow.


Thanks,

Michael

Am 14.04.23 um 16:50 schrieb Jacques Le Roux:

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.


* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

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 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 Eclipse 
compiler (used by UI to build the project) is not using the same 
way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is 
operating properly thanks to the backwards compatibility of Java"


It's a "philosophy" difference. I found it well explained in this 
stackoverflow answer (and links from there): 
https://s.apache.org/8n6op


You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module


Anyway, I need to fix that myself and will look at the best option 
when I'll get a chance. I tried some w/o success so far, . It's 
very annoying in Eclipse UI.
The best way could be to follow the point 7 at 
https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php 
I did not try yet, just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire 
project system, but if you import foreign libraries, they may 
bring their own version of a that package.


If you mouse over a faulty import statement in any of the java 
classes, you may find an error similiar to "The package [name] is 
accessible from more than one module:  java.xml". The 
 module refers to all foreign libraries stuffed into the 
classpath which counts as one huge unnamed module.


I'm surprised that this issue has not been reported yet, as it 
seems to be a fundamental one. My guess would be that we need to 
somehow update the build.gradle file.


On a side note: OfBiz actually starts and is operating properly 
thanks to the backwards compatiblity of Java, but the error 
messages remain.


Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 
(includes

Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse 
project, there
are a lot of errors (that I have have not experienced with OFBiz 
18).


Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 eventually worked.

Michael,
I have not yet looked at a solution for .settings. That"s indeed absolutely 
needed for JDK 17 to work properly in Eclipse (from 2023-03 version).

Leila,
sadly I tried to put a breakpoint at "CommunicationEventServices.groovy:489" without success (no stop) so far even when putting the stop at the top of 
the sendEmailDated method.

I wonder if it's no due to the OFBIZ-12801 specific error in the context of 
Codenarc...

Also I realised that the .classpath file I had before was approximatively the same than the new one generated using all the "Add" options (I see now 3 
"Remove" ones)

The (kind="src") add for the groovy file was a mistake. It's only an interchange between 
(kind="src") and (output="bin/main").
I though see this 3 lines at bottom:
    
    
    
The last one was at top before. So only the 1st 2 are new in the file.

I'll try more :)

Jacques

Le 17/04/2023 à 12:11, 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 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 into that yet. As I said it's not stopping me to debug, but Groovy, so unrelated to JDK 17. I use 
the last Eclipse ( 2023-03) and all last Eclipse plugins.

Good news at https://github.com/eclipse-jdt/eclipse.jdt/issues/57 closed :)

Maybe it's could also be due to a trick Leila gave me and I just applied.

Here is the copy of her message translated (Leila knows stuff but is a bit shy 
I think ;)

>

Hopefully the image will pass (I doubt). If not, it's only  a matter of using the "Add" options from the project "Groovy" option (like you have 
"team" there for instance )


Here is my answer to Leila so far:

<>

HTH

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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. 
Yes, as I could not get it working, I did not dig into that yet. As I said it's not stopping me to debug, but Groovy, so unrelated to JDK 17. I use 
the last Eclipse ( 2023-03) and all last Eclipse plugins.

Good news at https://github.com/eclipse-jdt/eclipse.jdt/issues/57 closed :)

Maybe it's could also be due to a trick Leila gave me and I just applied.

Here is the copy of her message translated (Leila knows stuff but is a bit shy 
I think ;)

>

Hopefully the image will pass (I doubt). If not, it's only  a matter of using the "Add" options from the project "Groovy" option (like you have "team" 
there for instance )


Here is my answer to Leila so far:

<>

HTH

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 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 into that yet. As I said it's not stopping me to debug, but Groovy, so unrelated to JDK 17. I use 
the last Eclipse ( 2023-03) and all last Eclipse plugins.


(3rd try after removing image, trying again, then using same Apache link 
 below instead of GH, the ML is not very friendly)
The message below in italic did not pass I guess because I put an image I now 
removed

--

/Good news at //"/ignoreUnnamedModuleForSplitPackage=enabled does not work"/aka https://github.com/eclipse-jdt/eclipse.jdt/issues/57 
//now closed :)/


//

/Maybe it's could also be due to a trick Leila gave me and I just applied. //
/

//

/Here is the copy of her message translated (Leila who knows stuff is a bit shy 
;)/

//

/>/

//

/Hopefully the image will pass (I doubt). //If not, it's only  a matter of using the "Add" options from the project "Groovy" option (like you have 
"team" there for instance )//

/ /
//Here is my answer to Leila so far:/

//

/<>

HTH/

//

/Jacques
/

//

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Daniel Watford]

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 take one of the offered
licenses for my OFBiz contributions. I am now happily running the latest
IntelliJ Ultimate, although memory usage appears to have jumped by
around 1GB since the previous version I had around 2 years ago.

If/when I take on some OFBiz consultancy work I'll be sure to purchase an
appropriate commercial license to provide appropriate cover.

Thanks,

Dan.


On Fri, 14 Apr 2023 at 20:47, Michael Brohl 
wrote:

> 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 the whole team and trying to get it
> running there also.
>
> Best regards,
>
> Michael
>
> Am 14.04.23 um 17:33 schrieb Daniel Watford:
> > 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 scripts. Using IntelliJ 'just
> > works'.
> >
> > I let my IntelliJ Ultimate license lapse a while ago so recently updated
> to
> > the latest Community edition. The only thing missing from the IntelliJ
> > Community edition for my work was Freemarker Template support.
> >
> > Every now and then I try using VS Code for OFBiz development but have not
> > been successful so far. Groovy/Gradle support is not there in vscode at
> the
> > moment and, as mentioned for Eclipse, I think we really need good Groovy
> > support in our IDE to develop OFBiz effectively.
> >
> > It's a shame about vscode as the ability to run your development
> > environment inside a container or in WSL2 is really useful.
> >
> > So, apologies that I haven't really answered the original question and
> have
> > gone slightly off topic, but my recommendation is to give IntelliJ a try.
> >
> > Dan.
> >
> >
> > On Fri, 14 Apr 2023 at 15:50, Jacques Le Roux <
> jacques.le.r...@les7arts.com>
> > wrote:
> >
> >> 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.
> >>
> >> * https://github.com/eclipse-jdt/eclipse.jdt/issues/57
> >>
> >> HTH
> >>
> >> Jacques
> >>
> >> Le 14/04/2023 à 15:31, Michael Brohl a écrit :
> >>> 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 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 Eclipse compiler
> >> (used by UI to build the project) is not using the same way than javac.
>  That's why, as Cheng Hu Shan said: " OFBiz actually starts and is
> >> operating properly thanks to the backwards compatibility of Java"
>  It's a "philosophy" difference. I found it well explained in this
> >> stackoverflow answer (and links from there): https://s.apache.org/8n6op
>  You may also read
> >>
> https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module
>  Anyway, I need to fix that myself and will look at the best option
> when
> >> I'll get a chance. I tried some w/o success so far, . It's very
> annoying in
>  Eclipse UI.
>  The best way could be to follow the point 7 at
> >>
> https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php
> >> I did not try yet,
>  just found it :)
> 
>  HTH
> 
>  Jacques
> 
>  Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :
> > 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 only exists 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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. 
Yes, as I could not get it working, I did not dig into that yet. As I said it's not stopping me to debug, but Groovy, so unrelated to JDK 17. I use 
the last Eclipse ( 2023-03) and all last Eclipse plugins.


The message below in italic did not pass I guess because I put an image I now 
removed

--
/Good news at //https://github.com/eclipse-jdt/eclipse.jdt/issues/57//now 
closed :)//
/

/Maybe it's could also be due to a trick Leila gave me and I just applied. //
/

//

/Here is the copy of her message translated (Leila knows stuff, but is a bit 
shy ;)/

//

/>/

//

/Hopefully the image will pass (I doubt). //If not, it's only  a matter of using the "Add" options from the project "Groovy" option (like you have 
"team" there for instance )//

/ /
//Here is my answer to Leila so far:/

//

/<>

HTH/

//

/Jacques
/

//

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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. 
Yes, as I could not get it working, I did not dig into that yet. As I said it's not stopping me to debug, but Groovy, so unrelated to JDK 17. I use 
the last Eclipse ( 2023-03) and all last Eclipse plugins.


(3rd try after removing image, trying again, then using same Apache link 
 below instead of GH, the ML is not very friendly)
The message below in italic did not pass I guess because I put an image I now 
removed

--

/Good news at //"/ignoreUnnamedModuleForSplitPackage=enabled does not work"/aka https://github.com/eclipse-jdt/eclipse.jdt/issues/57 
//now closed :)/


//

/Maybe it's could also be due to a trick Leila gave me and I just applied. //
/

//

/Here is the copy of her message translated (Leila who knows stuff is a bit shy 
;)/

//

/>/

//

/Hopefully the image will pass (I doubt). //If not, it's only  a matter of using the "Add" options from the project "Groovy" option (like you have 
"team" there for instance )//

/ /
//Here is my answer to Leila so far:/

//

/<>

HTH/

//

/Jacques
/

//

Fwd: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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@ofbiz.apache.org



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. 
Yes, as I could not get it working, I did not dig into that yet. As I said it's not stopping me to debug, but Groovy, so unrelated to JDK 17. I use 
the last Eclipse ( 2023-03) and all last Eclipse plugins.

Good news at https://github.com/eclipse-jdt/eclipse.jdt/issues/57 closed :)

Maybe it's could also be due to a trick Leila gave me and I just applied.

Here is the copy of her message translated (Leila knows stuff but is a bit shy 
I think ;)

<libraries are not added (or the source is badly configured).


If you see options with add instead of remove:

- add groovy dsl support

- add groovy libraries to classpath>>

Hopefully the image will pass (I doubt).
If not, it's only  a matter of using the "Add" options from the project "Groovy" option 
(like you have "team" there for instance )

Here is my answer to Leila so far:

<>

HTH

Jacques

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 into that yet. As I said it's not stopping me to debug, but Groovy, so unrelated to JDK 17. I use 
the last Eclipse ( 2023-03) and all last Eclipse plugins.

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

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 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.


All in all, some kind of showstopper using OFBiz with JDK 17 and Eclipse 
which has to be solved somehow.


Thanks,

Michael

Am 14.04.23 um 16:50 schrieb Jacques Le Roux:

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.


* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

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 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 Eclipse compiler 
(used by UI to build the project) is not using the same way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is 
operating properly thanks to the backwards compatibility of Java"


It's a "philosophy" difference. I found it well explained in this 
stackoverflow answer (and links from there): https://s.apache.org/8n6op


You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module


Anyway, I need to fix that myself and will look at the best option 
when I'll get a chance. I tried some w/o success so far, . It's very 
annoying in Eclipse UI.
The best way could be to follow the point 7 at 
https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php 
I did not try yet, just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire 
project system, but if you import foreign libraries, they may bring 
their own version of a that package.


If you mouse over a faulty import statement in any of the java 
classes, you may find an error similiar to "The package [name] is 
accessible from more than one module:  java.xml". The 
 module refers to all foreign libraries stuffed into the 
classpath which counts as one huge unnamed module.


I'm surprised that this issue has not been reported yet, as it 
seems to be a fundamental one. My guess would be that we need to 
somehow update the build.gradle file.


On a side note: OfBiz actually starts and is operating properly 
thanks to the backwards compatiblity of Java, but the error 
messages remain.


Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project, 
there

are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util 
line 527

Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

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 the whole team and trying to get it 
running there also.


Best regards,

Michael

Am 14.04.23 um 17:33 schrieb Daniel Watford:

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 scripts. Using IntelliJ 'just
works'.

I let my IntelliJ Ultimate license lapse a while ago so recently updated to
the latest Community edition. The only thing missing from the IntelliJ
Community edition for my work was Freemarker Template support.

Every now and then I try using VS Code for OFBiz development but have not
been successful so far. Groovy/Gradle support is not there in vscode at the
moment and, as mentioned for Eclipse, I think we really need good Groovy
support in our IDE to develop OFBiz effectively.

It's a shame about vscode as the ability to run your development
environment inside a container or in WSL2 is really useful.

So, apologies that I haven't really answered the original question and have
gone slightly off topic, but my recommendation is to give IntelliJ a try.

Dan.


On Fri, 14 Apr 2023 at 15:50, Jacques Le Roux 
wrote:


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.

* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

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 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 Eclipse compiler

(used by UI to build the project) is not using the same way than javac.

That's why, as Cheng Hu Shan said: " OFBiz actually starts and is

operating properly thanks to the backwards compatibility of Java"

It's a "philosophy" difference. I found it well explained in this

stackoverflow answer (and links from there): https://s.apache.org/8n6op

You may also read

https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module

Anyway, I need to fix that myself and will look at the best option when

I'll get a chance. I tried some w/o success so far, . It's very annoying in

Eclipse UI.
The best way could be to follow the point 7 at

https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php
I did not try yet,

just found it :)

HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire project system,

but if you import foreign libraries, they may bring their own version of a

that package.

If you mouse over a faulty import statement in any of the java

classes, you may find an error similiar to "The package [name] is
accessible from

more than one module:  java.xml". The  module refers

to all foreign libraries stuffed into the classpath which counts as one

huge unnamed module.

I'm surprised that this issue has not been reported yet, as it seems

to be a fundamental one. My guess would be that we need to somehow update
the

build.gradle file.

On a side note: OfBiz actually starts and is operating properly thanks

to the backwards compatiblity of Java, but the error messages remain.

Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project,

there

are a lot of 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Daniel Watford]

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 scripts. Using IntelliJ 'just
works'.

I let my IntelliJ Ultimate license lapse a while ago so recently updated to
the latest Community edition. The only thing missing from the IntelliJ
Community edition for my work was Freemarker Template support.

Every now and then I try using VS Code for OFBiz development but have not
been successful so far. Groovy/Gradle support is not there in vscode at the
moment and, as mentioned for Eclipse, I think we really need good Groovy
support in our IDE to develop OFBiz effectively.

It's a shame about vscode as the ability to run your development
environment inside a container or in WSL2 is really useful.

So, apologies that I haven't really answered the original question and have
gone slightly off topic, but my recommendation is to give IntelliJ a try.

Dan.


On Fri, 14 Apr 2023 at 15:50, Jacques Le Roux 
wrote:

> 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.
>
> * https://github.com/eclipse-jdt/eclipse.jdt/issues/57
>
> HTH
>
> Jacques
>
> Le 14/04/2023 à 15:31, Michael Brohl a écrit :
> > 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 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 Eclipse compiler
> (used by UI to build the project) is not using the same way than javac.
> >> That's why, as Cheng Hu Shan said: " OFBiz actually starts and is
> operating properly thanks to the backwards compatibility of Java"
> >>
> >> It's a "philosophy" difference. I found it well explained in this
> stackoverflow answer (and links from there): https://s.apache.org/8n6op
> >>
> >> You may also read
> https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module
> >>
> >> Anyway, I need to fix that myself and will look at the best option when
> I'll get a chance. I tried some w/o success so far, . It's very annoying in
> >> Eclipse UI.
> >> The best way could be to follow the point 7 at
> https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php
> I did not try yet,
> >> just found it :)
> >>
> >> HTH
> >>
> >> Jacques
> >>
> >> Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :
> >>> 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 only exists once in your entire project system,
> but if you import foreign libraries, they may bring their own version of a
> >>> that package.
> >>>
> >>> If you mouse over a faulty import statement in any of the java
> classes, you may find an error similiar to "The package [name] is
> accessible from
> >>> more than one module:  java.xml". The  module refers
> to all foreign libraries stuffed into the classpath which counts as one
> >>> huge unnamed module.
> >>>
> >>> I'm surprised that this issue has not been reported yet, as it seems
> to be a fundamental one. My guess would be that we need to somehow update
> the
> >>> build.gradle file.
> >>>
> >>> On a side note: OfBiz actually starts and is operating properly thanks
> to the backwards compatiblity of Java, but the error messages remain.
> >>>
> >>> Best regards,
> >>>
> >>> Cheng Hu Shan
> >>>
> >>>
> >>> Am 14.02.23 um 23:15 schrieb Carlos Navarro:
>  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 (includes
>  Incubating components) Version: 2022-12 (4.26.0)
>  OS: Windows 10
> 
>  However, as far as I import an existente OFBiz 22 Eclipse project,
> there
>  are a lot of errors 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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.

* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

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 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 Eclipse compiler (used by 
UI to build the project) is not using the same way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is operating properly 
thanks to the backwards compatibility of Java"

It's a "philosophy" difference. I found it well explained in this stackoverflow 
answer (and links from there): https://s.apache.org/8n6op

You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module

Anyway, I need to fix that myself and will look at the best option when I'll get a chance. I tried some w/o success so far, . It's very annoying in 
Eclipse UI.
The best way could be to follow the point 7 at https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php I did not try yet, 
just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire project system, but if you import foreign libraries, they may bring their own version of a 
that package.


If you mouse over a faulty import statement in any of the java classes, you may find an error similiar to "The package [name] is accessible from 
more than one module:  java.xml". The  module refers to all foreign libraries stuffed into the classpath which counts as one 
huge unnamed module.


I'm surprised that this issue has not been reported yet, as it seems to be a fundamental one. My guess would be that we need to somehow update the 
build.gradle file.


On a side note: OfBiz actually starts and is operating properly thanks to the 
backwards compatiblity of Java, but the error messages remain.

Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project, there
are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 527
Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 143 Java Problem
Comment cannot be resolved to a type WebToolsDbEvents.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 99
Java Problem
DefaultHandler cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 75
Java Problem
DefaultHandler cannot be resolved to a type WebAppUtil.java
/ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 261 Java
Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 115
Java Problem
DocumentBuilder cannot be resolved to a type 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

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 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 Eclipse compiler 
(used by UI to build the project) is not using the same way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is 
operating properly thanks to the backwards compatibility of Java"


It's a "philosophy" difference. I found it well explained in this 
stackoverflow answer (and links from there): https://s.apache.org/8n6op


You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module


Anyway, I need to fix that myself and will look at the best option 
when I'll get a chance. I tried some w/o success so far, . It's very 
annoying in Eclipse UI.
The best way could be to follow the point 7 at 
https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php 
I did not try yet, just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire project 
system, but if you import foreign libraries, they may bring their own 
version of a that package.


If you mouse over a faulty import statement in any of the java 
classes, you may find an error similiar to "The package [name] is 
accessible from more than one module:  java.xml". The 
 module refers to all foreign libraries stuffed into the 
classpath which counts as one huge unnamed module.


I'm surprised that this issue has not been reported yet, as it seems 
to be a fundamental one. My guess would be that we need to somehow 
update the build.gradle file.


On a side note: OfBiz actually starts and is operating properly 
thanks to the backwards compatiblity of Java, but the error messages 
remain.


Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project, 
there

are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util 
line 527

Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 143 Java Problem
Comment cannot be resolved to a type WebToolsDbEvents.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools 
line 99

Java Problem
DefaultHandler cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util 
line 75

Java Problem
DefaultHandler cannot be resolved to a type WebAppUtil.java
/ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 
261 Java

Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security 
line 115

Java Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security 
line 152

Java Problem
DocumentBuilder cannot be resolved to a type GatewayResponse.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway 


line 169 Java Problem
DocumentBuilder cannot be resolved to a type ModelService.java

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 changing "enable" to lowercase) 
has at least hidden the amount of errors.


I came across this blog post: 
https://moduliertersingvogel.de/2017/12/15/building-java-9-projects-with-eclipse-and-gradle/

The first code block successfully moved all foreign library jars into the module path. But I couldn't get the generation of module-info files to 
work. Maybe this can help you.



Best regards

Cheng Hu Shan

Am 16.02.23 um 17:59 schrieb Jacques Le Roux:

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 Eclipse compiler (used by 
UI to build the project) is not using the same way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is operating properly 
thanks to the backwards compatibility of Java"

It's a "philosophy" difference. I found it well explained in this stackoverflow 
answer (and links from there): https://s.apache.org/8n6op

You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module

Anyway, I need to fix that myself and will look at the best option when I'll get a chance. I tried some w/o success so far, . It's very annoying in 
Eclipse UI.
The best way could be to follow the point 7 at https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php I did not try yet, 
just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire project system, but if you import foreign libraries, they may bring their own version of a 
that package.


If you mouse over a faulty import statement in any of the java classes, you may find an error similiar to "The package [name] is accessible from 
more than one module:  java.xml". The  module refers to all foreign libraries stuffed into the classpath which counts as one 
huge unnamed module.


I'm surprised that this issue has not been reported yet, as it seems to be a fundamental one. My guess would be that we need to somehow update the 
build.gradle file.


On a side note: OfBiz actually starts and is operating properly thanks to the 
backwards compatiblity of Java, but the error messages remain.

Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project, there
are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 527
Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 143 Java Problem
Comment cannot be resolved to a type WebToolsDbEvents.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 99
Java Problem
DefaultHandler cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 75
Java Problem
DefaultHandler cannot be resolved to a type WebAppUtil.java
/ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 261 Java
Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Cheng Hu Shan]

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: 
https://moduliertersingvogel.de/2017/12/15/building-java-9-projects-with-eclipse-and-gradle/


The first code block successfully moved all foreign library jars into 
the module path. But I couldn't get the generation of module-info files 
to work. Maybe this can help you.



Best regards

Cheng Hu Shan

Am 16.02.23 um 17:59 schrieb Jacques Le Roux:

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 Eclipse compiler 
(used by UI to build the project) is not using the same way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is 
operating properly thanks to the backwards compatibility of Java"


It's a "philosophy" difference. I found it well explained in this 
stackoverflow answer (and links from there): https://s.apache.org/8n6op


You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module


Anyway, I need to fix that myself and will look at the best option 
when I'll get a chance. I tried some w/o success so far, . It's very 
annoying in Eclipse UI.
The best way could be to follow the point 7 at 
https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php 
I did not try yet, just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire project 
system, but if you import foreign libraries, they may bring their own 
version of a that package.


If you mouse over a faulty import statement in any of the java 
classes, you may find an error similiar to "The package [name] is 
accessible from more than one module:  java.xml". The 
 module refers to all foreign libraries stuffed into the 
classpath which counts as one huge unnamed module.


I'm surprised that this issue has not been reported yet, as it seems 
to be a fundamental one. My guess would be that we need to somehow 
update the build.gradle file.


On a side note: OfBiz actually starts and is operating properly 
thanks to the backwards compatiblity of Java, but the error messages 
remain.


Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project, 
there

are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util 
line 527

Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 143 Java Problem
Comment cannot be resolved to a type WebToolsDbEvents.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools 
line 99

Java Problem
DefaultHandler cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util 
line 75

Java Problem
DefaultHandler cannot be resolved to a type WebAppUtil.java
/ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 
261 Java

Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security 
line 115

Java Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Carlos Navarro]

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?
> 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 Eclipse compiler (used
> by UI to build the project) is not using the same way than javac.
> That's why, as Cheng Hu Shan said: " OFBiz actually starts and is
> operating properly thanks to the backwards compatibility of Java"
>
> It's a "philosophy" difference. I found it well explained in this
> stackoverflow answer (and links from there): https://s.apache.org/8n6op
>
> You may also read
> https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module
>
> Anyway, I need to fix that myself and will look at the best option when
> I'll get a chance. I tried some w/o success so far, . It's very annoying in
> Eclipse UI.
> The best way could be to follow the point 7 at
> https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php
> I did not try yet,
> just found it :)
>
> HTH
>
> Jacques
>
> Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :
> > 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 only exists once in your entire project system,
> but if you import foreign libraries, they may bring their own version of a
> > that package.
> >
> > If you mouse over a faulty import statement in any of the java classes,
> you may find an error similiar to "The package [name] is accessible from
> > more than one module:  java.xml". The  module refers
> to all foreign libraries stuffed into the classpath which counts as one
> huge
> > unnamed module.
> >
> > I'm surprised that this issue has not been reported yet, as it seems to
> be a fundamental one. My guess would be that we need to somehow update the
> > build.gradle file.
> >
> > On a side note: OfBiz actually starts and is operating properly thanks
> to the backwards compatiblity of Java, but the error messages remain.
> >
> > Best regards,
> >
> > Cheng Hu Shan
> >
> >
> > Am 14.02.23 um 23:15 schrieb Carlos Navarro:
> >> 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 (includes
> >> Incubating components) Version: 2022-12 (4.26.0)
> >> OS: Windows 10
> >>
> >> However, as far as I import an existente OFBiz 22 Eclipse project, there
> >> are a lot of errors (that I have have not experienced with OFBiz 18).
> >>
> >> Here are some of them (100 of 3967 errors):
> >>
> >>
> >> Description Resource Path Location Type
> >> Attributes cannot be resolved to a type EntitySaxReader.java
> >> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line
> 527
> >> Java Problem
> >> Comment cannot be resolved to a type LabelManagerFactory.java
> >>
> /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
> >> line 164 Java Problem
> >> Comment cannot be resolved to a type LabelManagerFactory.java
> >>
> /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
> >> line 169 Java Problem
> >> Comment cannot be resolved to a type SaveLabelsToXmlFile.java
> >>
> /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
> >> line 128 Java Problem
> >> Comment cannot be resolved to a type SaveLabelsToXmlFile.java
> >>
> /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
> >> line 143 Java Problem
> >> Comment cannot be resolved to a type WebToolsDbEvents.java
> >> /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line
> 99
> >> Java Problem
> >> DefaultHandler cannot be resolved to a type EntitySaxReader.java
> >> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line
> 75
> >> Java Problem
> >> DefaultHandler cannot be resolved to a type WebAppUtil.java
> >> /ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 261
> Java
> >> Problem
> >> DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
> >> /ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line
> 115
> >> Java Problem
> >> DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
> >> /ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line
> 152
> >> Java Problem
> >> 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Jacques Le Roux]

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 Eclipse compiler (used by 
UI to build the project) is not using the same way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is operating properly 
thanks to the backwards compatibility of Java"

It's a "philosophy" difference. I found it well explained in this stackoverflow 
answer (and links from there): https://s.apache.org/8n6op

You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module

Anyway, I need to fix that myself and will look at the best option when I'll get a chance. I tried some w/o success so far, . It's very annoying in 
Eclipse UI.
The best way could be to follow the point 7 at https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php I did not try yet, 
just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

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 only exists once in your entire project system, but if you import foreign libraries, they may bring their own version of a 
that package.


If you mouse over a faulty import statement in any of the java classes, you may find an error similiar to "The package [name] is accessible from 
more than one module:  java.xml". The  module refers to all foreign libraries stuffed into the classpath which counts as one huge 
unnamed module.


I'm surprised that this issue has not been reported yet, as it seems to be a fundamental one. My guess would be that we need to somehow update the 
build.gradle file.


On a side note: OfBiz actually starts and is operating properly thanks to the 
backwards compatiblity of Java, but the error messages remain.

Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project, there
are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 527
Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 143 Java Problem
Comment cannot be resolved to a type WebToolsDbEvents.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 99
Java Problem
DefaultHandler cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 75
Java Problem
DefaultHandler cannot be resolved to a type WebAppUtil.java
/ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 261 Java
Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 115
Java Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 152
Java Problem
DocumentBuilder cannot be resolved to a type GatewayResponse.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway
line 169 Java Problem
DocumentBuilder cannot be resolved to a type ModelService.java
/ofbiz/framework/service/src/main/java/org/apache/ofbiz/service line 1883
Java Problem
DocumentBuilder cannot be resolved to a type WebToolsServices.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 163
Java Problem
DocumentBuilderFactory cannot be resolved CsrfUtilTests.java

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Cheng Hu Shan]

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 only exists once in your entire project system, 
but if you import foreign libraries, they may bring their own version of 
a that package.


If you mouse over a faulty import statement in any of the java classes, 
you may find an error similiar to "The package [name] is accessible from 
more than one module:  java.xml". The  module refers 
to all foreign libraries stuffed into the classpath which counts as one 
huge unnamed module.


I'm surprised that this issue has not been reported yet, as it seems to 
be a fundamental one. My guess would be that we need to somehow update 
the build.gradle file.


On a side note: OfBiz actually starts and is operating properly thanks 
to the backwards compatiblity of Java, but the error messages remain.


Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project, there
are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 527
Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 143 Java Problem
Comment cannot be resolved to a type WebToolsDbEvents.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 99
Java Problem
DefaultHandler cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 75
Java Problem
DefaultHandler cannot be resolved to a type WebAppUtil.java
/ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 261 Java
Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 115
Java Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 152
Java Problem
DocumentBuilder cannot be resolved to a type GatewayResponse.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway
line 169 Java Problem
DocumentBuilder cannot be resolved to a type ModelService.java
/ofbiz/framework/service/src/main/java/org/apache/ofbiz/service line 1883
Java Problem
DocumentBuilder cannot be resolved to a type WebToolsServices.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 163
Java Problem
DocumentBuilderFactory cannot be resolved CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 114
Java Problem
DocumentBuilderFactory cannot be resolved CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 151
Java Problem
DocumentBuilderFactory cannot be resolved GatewayResponse.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway
line 167 Java Problem
DocumentBuilderFactory cannot be resolved ModelService.java
/ofbiz/framework/service/src/main/java/org/apache/ofbiz/service line 1882
Java Problem
DocumentBuilderFactory cannot be resolved WebToolsServices.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 163
Java Problem
DocumentBuilderFactory cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 114
Java Problem
DocumentBuilderFactory cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 151
Java Problem
DocumentBuilderFactory cannot be resolved to a type GatewayResponse.java

OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Carlos Navarro]

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 (includes
Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22 Eclipse project, there
are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 527
Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
line 143 Java Problem
Comment cannot be resolved to a type WebToolsDbEvents.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 99
Java Problem
DefaultHandler cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 75
Java Problem
DefaultHandler cannot be resolved to a type WebAppUtil.java
/ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 261 Java
Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 115
Java Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 152
Java Problem
DocumentBuilder cannot be resolved to a type GatewayResponse.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway
line 169 Java Problem
DocumentBuilder cannot be resolved to a type ModelService.java
/ofbiz/framework/service/src/main/java/org/apache/ofbiz/service line 1883
Java Problem
DocumentBuilder cannot be resolved to a type WebToolsServices.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 163
Java Problem
DocumentBuilderFactory cannot be resolved CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 114
Java Problem
DocumentBuilderFactory cannot be resolved CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 151
Java Problem
DocumentBuilderFactory cannot be resolved GatewayResponse.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway
line 167 Java Problem
DocumentBuilderFactory cannot be resolved ModelService.java
/ofbiz/framework/service/src/main/java/org/apache/ofbiz/service line 1882
Java Problem
DocumentBuilderFactory cannot be resolved WebToolsServices.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 163
Java Problem
DocumentBuilderFactory cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 114
Java Problem
DocumentBuilderFactory cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 151
Java Problem
DocumentBuilderFactory cannot be resolved to a type GatewayResponse.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway
line 167 Java Problem
DocumentBuilderFactory cannot be resolved to a type ModelService.java
/ofbiz/framework/service/src/main/java/org/apache/ofbiz/service line 1882
Java Problem
Document cannot be resolved to a type BirtServices.java
/ofbiz/plugins/birt/src/main/java/org/apache/ofbiz/birt/flexible line 336
Java Problem
Document cannot be resolved to a type CCPaymentServices.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce
line 68 Java Problem
Document cannot be resolved to a type CCPaymentServices.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce
line 71 Java Problem
Document cannot be resolved to a type CCPaymentServices.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce
line 100 Java Problem
Document cannot be resolved to a type CCPaymentServices.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce
line 102 Java Problem
Document cannot be resolved to a type CCPaymentServices.java