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 <event 
type="groovy"
path="..." /> elements in the controller.xml files and <service
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<michael.br...@ecomify.de>
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 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, 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: <unnamed> 
java.xml".
The <unnamed> 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/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

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 134 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 137 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 169 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 172 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 226 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 229 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 261 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 264 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 304 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 381 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 427 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 461 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 495 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 529 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 563 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 597 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 622 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 640 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 652 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 739 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 836 Java Problem
Document cannot be resolved to a type 
CCPaymentServices.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce 


line 891 Java Problem
Document cannot be resolved to a type CdyneServices.java
/ofbiz/framework/common/src/main/java/org/apache/ofbiz/common 

line 61 Java
Problem
Document cannot be resolved to a type ComponentConfig.java

/ofbiz/framework/base/src/main/java/org/apache/ofbiz/base/component
line
409 Java Problem
Document cannot be resolved to a type 
ComponentLoaderConfig.java

/ofbiz/framework/base/src/main/java/org/apache/ofbiz/base/component
line 80
Java Problem
Document cannot be resolved to a type 
ComponentLoaderConfig.java

/ofbiz/framework/base/src/main/java/org/apache/ofbiz/base/component
line
161 Java Problem
Document cannot be resolved to a type
ComponentResourceHandler.java

/ofbiz/framework/base/src/main/java/org/apache/ofbiz/base/component
line 73
Java Problem
Document cannot be resolved to a type ConfigXMLReader.java

/ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control
line
232 Java Problem
Document cannot be resolved to a type CsrfUtilTests.java

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

/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security
line 153
Java Problem
Document cannot be resolved to a type 
DataResourceWorker.java

/ofbiz/applications/content/src/main/java/org/apache/ofbiz/content/data 

line 783 Java Problem
Document cannot be resolved to a type 
DataResourceWorker.java

/ofbiz/applications/content/src/main/java/org/apache/ofbiz/content/data 

line 813 Java Problem
Document cannot be resolved to a type Delegator.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity 

line 702 Java
Problem
Document cannot be resolved to a type DhlServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl 


line 293 Java Problem
Document cannot be resolved to a type DhlServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl 


line 309 Java Problem
Document cannot be resolved to a type DhlServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl 


line 395 Java Problem
Document cannot be resolved to a type DhlServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl 


line 428 Java Problem
Document cannot be resolved to a type DhlServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl 


line 447 Java Problem
Document cannot be resolved to a type DhlServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl 


line 796 Java Problem
Document cannot be resolved to a type DhlServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl 


line 854 Java Problem
Document cannot be resolved to a type DhlServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl 


line 855 Java Problem
Document cannot be resolved to a type DispatchContext.java
/ofbiz/framework/service/src/main/java/org/apache/ofbiz/service 

line 241
Java Problem
Document cannot be resolved to a type 
DynamicViewEntity.java

/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/model
line 98
Java Problem
Document cannot be resolved to a type 
DynamicViewEntity.java

/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/model
line
109 Java Problem
Document cannot be resolved to a type EbayHelper.java
/ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay 
line
103 Java
Problem
Document cannot be resolved to a type 
EbayOrderServices.java
/ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay 
line
180 Java
Problem
Document cannot be resolved to a type 
EbayOrderServices.java
/ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay 
line
230 Java
Problem
Document cannot be resolved to a type 
EbayOrderServices.java
/ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay 
line
267 Java
Problem
Document cannot be resolved to a type 
EbayOrderServices.java
/ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay 
line
454 Java
Problem
Document cannot be resolved to a type 
EbayOrderServices.java
/ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay 
line
681 Java
Problem
Document cannot be resolved to a type 
EbayOrderServices.java
/ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay 
line
993 Java
Problem
Document cannot be resolved to a type EntitySaxReader.java

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

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

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

/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util
line 561
Java Problem
Document cannot be resolved to a type 
EntitySyncServices.java

/ofbiz/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization 


line 483 Java Problem
Document cannot be resolved to a type 
EntitySyncServices.java

/ofbiz/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization 


line 561 Java Problem
Document cannot be resolved to a type FedexServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/fedex 


line 381 Java Problem
Document cannot be resolved to a type FedexServices.java

/ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/fedex 


line 1020 Java Problem
Document cannot be resolved to a type FormFactory.java

/ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model
line 58
Java Problem
Document cannot be resolved to a type FormFactory.java

/ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model
line 71
Java Problem
Document cannot be resolved to a type FormFactory.java

/ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model
line
101 Java Problem
Document cannot be resolved to a type FormFactory.java

/ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model
line
114 Java Problem
Document cannot be resolved to a type FormFactory.java

/ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model
line
142 Java Problem
Document cannot be resolved to a type GatewayResponse.java

/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway 


line 170 Java Problem
Document cannot be resolved to a type GenericDelegator.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity 

line 2182
Java Problem
Document cannot be resolved to a type GenericEntity.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity 

line 1230
Java Problem
Document cannot be resolved to a type GenericEntity.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity 

line 1231
Java Problem
Document cannot be resolved to a type GenericEntity.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity 

line 1241
Java Problem
Document cannot be resolved to a type GenericEntity.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity 

line 1245
Java Problem
Document cannot be resolved to a type GenericEntity.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity 

line 1268
Java Problem
Document cannot be resolved to a type GenericEntity.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity 

line 1277
Java Problem
Document cannot be resolved to a type GridFactory.java

/ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model
line 60
Java Problem

Any clue on how to fix these issues?

Thanks.

Carlos Navarro