Imports of required classes have classname only without package path within the class compiled by maven @Wayne Fay

[b***@commcity.ch]

Sorry this answer is not helpful.

m2e tells me, it's not their problem, it's maven and you tell me the
opposite!

I think it's neither IBM, because changing the Glassfish project to use
the IBM J9 VM instead of oracle jdk 1.6.0_45 compiles to correct classes,
as with the oracle jdk!

In opposition compiling within the WebSphere project on the command line
with:
mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
doesn't show any Error and the classes are defective independent of the
JAVA_HOME setting, either IBM J9 VM or the oracle jdk!

Further the jdk to use is declared within the pom with:

<plugin>
<artifactId>maven-compiler-plugin
</artifactId>
<version>
${version.maven-compiler-plugin}</version>
<configuration>
<source>
${version.java.jdk}</source>
<target>
${version.java.jdk}</target>
<executable>
"${env.WAS8_HOME}/java/bin/javac.exe"</executable>
<showWarnings>true</
showWarnings>
<fork>true</fork>
</configuration>
</plugin>

The environment variable has been verified and is correct. Confirmed by
the logged output:

[DEBUG] properties used {env.INTEL64_HOME=C:\Program Files\Intel,
env.CONFIGSETROOT=C:\Windows\ConfigSetRoot,
java.home=C:\programs\ibm\WebSphere\AppServer\java\jre,
version.java.jdk=1.6, env.INTEL_MGMT_ENG_COMP=Intel(R) Management Engine
Components,
classworlds.conf=C:\daten\projects\junoWorkspace\MonteRosaWAS\.metadata\.plugins\org.eclipse.m2e.launching\launches\m2conf1670186333626179780.tmp,
version.org.jboss.arquillian.graphene=2.0.0.Final, env.COMMPATH=C:\Program
Files\Lenovo\Communications Utility, version.maven-assembly-plugin=2.4,
java.endorsed.dirs=C:\programs\ibm\WebSphere\AppServer\java\jre\lib\endorsed,
java.assistive=ON, env.USERNAME=juerg, java.fullversion=JRE 1.6.0 IBM J9
2.6 Windows 7 amd64-64 Compressed References 20130301_140166 (JIT enabled,
AOT enabled)
J9VM - R26_Java626_SR5_FP1_20130301_0937_B140166
JIT - r11.b03_20130131_32403
GC - R26_Java626_SR5_FP1_20130301_0937_B140166_CMPRSS
J9CL - 20130301_140166, java.vendor.url=http://www.ibm.com/,
env.INCLUDE=C:\programs\ibm\SQLLIB\INCLUDE;C:\programs\ibm\SQLLIB\LIB,
env.COMPUTERNAME=MIRA,
site.pmd.rulesets=C:\daten\projects\junoWorkspace\MonteRosaWAS\Reports\..\Site\src\pmd\rulesets,
java.version=1.6.0, env.APP_WAS_HOME=C:\programs\ibm\WebSphere\AppServer,
....
The whole concludes with:

[INFO] Reactor Summary:
[INFO]
[INFO] Site - Agile Storyboard Editor/Document-generator . SUCCESS
[0.000s]
[INFO] MonteRosaCommon ................................... SUCCESS
[2.464s]
[INFO] MonteRosa CCC ..................................... SUCCESS
[0.812s]
[INFO] MonteRosa EJB ..................................... SUCCESS
[1.716s]
[INFO] Monterosa GUI ..................................... SUCCESS
[2.948s]
[INFO] Reports ........................................... SUCCESS
[0.764s]
[INFO] MonteRosa Application ............................. SUCCESS
[0.718s]
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 9.766s
[INFO] Finished at: Mon Nov 04 17:02:06 CET 2013
[INFO] Final Memory: 11M/20M
[INFO]
------------------------------------------------------------------------

But the compiled classes are not usable at all. Of course, it's a
multi-module project, which may be the origin of the problem. I can only
say, it works with the glassfish configuration, but it don't with the
WebSphere configuration! It' worked for a while with WAS too but then it
stopped to work for an unknown reason.

I don't know what is going on behind the scenes, hence I need a little
help to resolve the issue. Being sent from one to the next is not exactly
the expected kind of help.

[Ron Wheeler]

It looks like you have one of those problems that requires multiple sets
of expertise and is more complicated than a volunteer can solve in a few
minutes.

Is this an important problem?
Do you have a consulting budget to fix it?

One of the problems of getting your support from a community of
volunteers is that you are depending on the kindness and interest of
strangers.

If your problem is not clearly within the main area of interest of the
community or is wrapped up in a development methodology that is not
widely shared, you may have difficulty finding someone with the time,
the interest and skill to fix your problem. We all have our own dragons
to slay.

Perhaps you should start with a small "Hello World" and extend it to the
point where the "compiled classes are useless". It is hard to see how
compiled classes would be defective in any way but your tests will soon
point to the thing that makes this happen.

Ron

Post by b***@commcity.ch
Sorry this answer is not helpful.
m2e tells me, it's not their problem, it's maven and you tell me the
opposite!
I think it's neither IBM, because changing the Glassfish project to use
the IBM J9 VM instead of oracle jdk 1.6.0_45 compiles to correct classes,
as with the oracle jdk!
In opposition compiling within the WebSphere project on the command line
mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
doesn't show any Error and the classes are defective independent of the
JAVA_HOME setting, either IBM J9 VM or the oracle jdk!
<plugin>
<artifactId>maven-compiler-plugin
</artifactId>
<version>
${version.maven-compiler-plugin}</version>
<configuration>
<source>
${version.java.jdk}</source>
<target>
${version.java.jdk}</target>
<executable>
"${env.WAS8_HOME}/java/bin/javac.exe"</executable>
<showWarnings>true</
showWarnings>
<fork>true</fork>
</configuration>
</plugin>
The environment variable has been verified and is correct. Confirmed by
[DEBUG] properties used {env.INTEL64_HOME=C:\Program Files\Intel,
env.CONFIGSETROOT=C:\Windows\ConfigSetRoot,
java.home=C:\programs\ibm\WebSphere\AppServer\java\jre,
version.java.jdk=1.6, env.INTEL_MGMT_ENG_COMP=Intel(R) Management Engine
Components,
classworlds.conf=C:\daten\projects\junoWorkspace\MonteRosaWAS\.metadata\.plugins\org.eclipse.m2e.launching\launches\m2conf1670186333626179780.tmp,
version.org.jboss.arquillian.graphene=2.0.0.Final, env.COMMPATH=C:\Program
Files\Lenovo\Communications Utility, version.maven-assembly-plugin=2.4,
java.endorsed.dirs=C:\programs\ibm\WebSphere\AppServer\java\jre\lib\endorsed,
java.assistive=ON, env.USERNAME=juerg, java.fullversion=JRE 1.6.0 IBM J9
2.6 Windows 7 amd64-64 Compressed References 20130301_140166 (JIT enabled,
AOT enabled)
J9VM - R26_Java626_SR5_FP1_20130301_0937_B140166
JIT - r11.b03_20130131_32403
GC - R26_Java626_SR5_FP1_20130301_0937_B140166_CMPRSS
J9CL - 20130301_140166, java.vendor.url=http://www.ibm.com/,
env.INCLUDE=C:\programs\ibm\SQLLIB\INCLUDE;C:\programs\ibm\SQLLIB\LIB,
env.COMPUTERNAME=MIRA,
site.pmd.rulesets=C:\daten\projects\junoWorkspace\MonteRosaWAS\Reports\..\Site\src\pmd\rulesets,
java.version=1.6.0, env.APP_WAS_HOME=C:\programs\ibm\WebSphere\AppServer,
....
[INFO]
[INFO] Site - Agile Storyboard Editor/Document-generator . SUCCESS
[0.000s]
[INFO] MonteRosaCommon ................................... SUCCESS
[2.464s]
[INFO] MonteRosa CCC ..................................... SUCCESS
[0.812s]
[INFO] MonteRosa EJB ..................................... SUCCESS
[1.716s]
[INFO] Monterosa GUI ..................................... SUCCESS
[2.948s]
[INFO] Reports ........................................... SUCCESS
[0.764s]
[INFO] MonteRosa Application ............................. SUCCESS
[0.718s]
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 9.766s
[INFO] Finished at: Mon Nov 04 17:02:06 CET 2013
[INFO] Final Memory: 11M/20M
[INFO]
------------------------------------------------------------------------
But the compiled classes are not usable at all. Of course, it's a
multi-module project, which may be the origin of the problem. I can only
say, it works with the glassfish configuration, but it don't with the
WebSphere configuration! It' worked for a while with WAS too but then it
stopped to work for an unknown reason.
I don't know what is going on behind the scenes, hence I need a little
help to resolve the issue. Being sent from one to the next is not exactly
the expected kind of help.

[Wayne Fay]

Post by b***@commcity.ch
Sorry this answer is not helpful.

If you are ever unsatisfied with the advice that you receive from this
list, you are immediately entitled to a FULL REFUND. Calling people
out is more likely to get you added to their ban/ignore list than
anything else. Would you simply prefer that your emails are ignored if
no one can provide an immediate and concise answer to your problems?

Post by b***@commcity.ch
m2e tells me, it's not their problem, it's maven and you tell me the
opposite!

I said that you would need to talk to the m2e people about m2e
problems and that this list could help you with command-line Maven
only. That was and still is true.

Post by b***@commcity.ch
I think it's neither IBM, because changing the Glassfish project to use
the IBM J9 VM instead of oracle jdk 1.6.0_45 compiles to correct classes,
as with the oracle jdk!

...

Post by b***@commcity.ch
In opposition compiling within the WebSphere project on the command line
mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
doesn't show any Error and the classes are defective independent of the
JAVA_HOME setting, either IBM J9 VM or the oracle jdk!

It sounds to me like the one constant in all your failures is your
WebSphere project itself. You said the following:
"glassfish project" + ibm j9 vm = works
"glassfish project" + oracle jdk 1.6.0_45 = works
"websphere project" + any jvm = fails

If this is true, it seems like you will need to provide a lot more
information (and maybe even a small sample project) about the
Websphere project you are attempting to build.

Post by b***@commcity.ch
${version.maven-compiler-plugin}</version>

...

Post by b***@commcity.ch
${version.java.jdk}</source>

...

Post by b***@commcity.ch
"${env.WAS8_HOME}/java/bin/javac.exe"</executable>

Replace all those ${...} with hardcoded values for testing. Once it is
working properly, you can go back and use the variables instead.

Post by b***@commcity.ch
The environment variable has been verified and is correct. Confirmed by
[DEBUG] properties used {env.INTEL64_HOME=C:\Program Files\Intel,

This is not especially useful. Far more useful is to look at the
compiler plugin output lines (emitted with -X) that show you the exact
command that was used when calling your compiler. I said this in my

Post by b***@commcity.ch

Maven (command line) simply calls out to the JDK installed on your
system. You can use "mvn -X" to see the actual command that Maven uses
to call javac. If you are experiencing problems with the output of

By looking at & copy/pasting the output, you can do your own
compilation of classes etc in the various modules and swap out the
JDK/javac being used and all manner of things. If you did this, you
would probably find the one thing which consistently breaks your
builds which would clue you into the root cause of your current
troubles.

Post by b***@commcity.ch
But the compiled classes are not usable at all. Of course, it's a
multi-module project, which may be the origin of the problem. I can only
say, it works with the glassfish configuration, but it don't with the
WebSphere configuration! It' worked for a while with WAS too but then it
stopped to work for an unknown reason.

What things are different between "the glassfish configuration" and
"the websphere configuration"? Can you enumerate that list? Bear in
mind this list has no particular expertise on Glassfish nor on
Websphere, so we might tell you (gasp) to go ask for product-specific
help from one of those communities.

Post by b***@commcity.ch
I don't know what is going on behind the scenes, hence I need a little
help to resolve the issue. Being sent from one to the next is not exactly
the expected kind of help.

Perhaps you need to adjust your "expectations" entirely. No one here
is getting paid to help you. We are all volunteers. Feel free to reply
more & we're happy to help but seriously, lose the attitude.

Wayne

[b***@commcity.ch]

Hi,
this is much better.

Based on my actual knowledge, yes I believe it must have a relation with
the Juno Version of eclipse, but I don't know how and why.

The differences between the two flavors of project are minimal and due to
the differences of App-Server and Databases used. If Java would have
conditional compilation the differences could be handled much easier by
this. For instance the server and jsf-implementation related differences
requires to have two web.xml files, checked out from separated branches of
svn. Or the login / logout methods within one class differs slightly due
to the different implementations of the servers, etc. I hardly believe
those differences being the cause of the troubles.

Fact is: The outcome of the maven compilation is the same for both cases.
Either started from the command line or started within the juno IDE.

I'm actually checking out the project into an entirely new kepler SP1
workplace, from where I'll try a build from the command line. I'll tell
you the outcome.

I'll try this before I installing m2e-wtp. Hence, I'll just use subclipse
to checkout the project from the svn server. I choose this approach,
instead of svn tortoise for instance, to be able to analyze what will
happen after installation of the m2e-wtp-Plugin.

Unfortunately the WAS-Plugin is still not available for Kepler, which
means I must still stick to juno if I want debug the code for WebSphere.





From: Wayne Fay <***@gmail.com>
To: Maven Users List <***@maven.apache.org>
Date: 05.11.2013 07:47
Subject: Re: Imports of required classes have classname only

Post by b***@commcity.ch
Sorry this answer is not helpful.

If you are ever unsatisfied with the advice that you receive from this
list, you are immediately entitled to a FULL REFUND. Calling people
out is more likely to get you added to their ban/ignore list than
anything else. Would you simply prefer that your emails are ignored if
no one can provide an immediate and concise answer to your problems?

Post by b***@commcity.ch
m2e tells me, it's not their problem, it's maven and you tell me the
opposite!

I said that you would need to talk to the m2e people about m2e
problems and that this list could help you with command-line Maven
only. That was and still is true.

Post by b***@commcity.ch
I think it's neither IBM, because changing the Glassfish project to use
the IBM J9 VM instead of oracle jdk 1.6.0_45 compiles to correct classes,
as with the oracle jdk!

...

Post by b***@commcity.ch
In opposition compiling within the WebSphere project on the command line
mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
doesn't show any Error and the classes are defective independent of the
JAVA_HOME setting, either IBM J9 VM or the oracle jdk!

It sounds to me like the one constant in all your failures is your
WebSphere project itself. You said the following:
"glassfish project" + ibm j9 vm = works
"glassfish project" + oracle jdk 1.6.0_45 = works
"websphere project" + any jvm = fails

If this is true, it seems like you will need to provide a lot more
information (and maybe even a small sample project) about the
Websphere project you are attempting to build.

Post by b***@commcity.ch
${version.maven-compiler-plugin}</version>

...

Post by b***@commcity.ch
${version.java.jdk}</source>

...

Post by b***@commcity.ch
"${env.WAS8_HOME}/java/bin/javac.exe"</executable>

Replace all those ${...} with hardcoded values for testing. Once it is
working properly, you can go back and use the variables instead.

Post by b***@commcity.ch
The environment variable has been verified and is correct. Confirmed by
[DEBUG] properties used {env.INTEL64_HOME=C:\Program Files\Intel,

This is not especially useful. Far more useful is to look at the
compiler plugin output lines (emitted with -X) that show you the exact
command that was used when calling your compiler. I said this in my

Post by b***@commcity.ch

Maven (command line) simply calls out to the JDK installed on your
system. You can use "mvn -X" to see the actual command that Maven uses
to call javac. If you are experiencing problems with the output of

By looking at & copy/pasting the output, you can do your own
compilation of classes etc in the various modules and swap out the
JDK/javac being used and all manner of things. If you did this, you
would probably find the one thing which consistently breaks your
builds which would clue you into the root cause of your current
troubles.

Post by b***@commcity.ch
But the compiled classes are not usable at all. Of course, it's a
multi-module project, which may be the origin of the problem. I can only
say, it works with the glassfish configuration, but it don't with the
WebSphere configuration! It' worked for a while with WAS too but then it
stopped to work for an unknown reason.

What things are different between "the glassfish configuration" and
"the websphere configuration"? Can you enumerate that list? Bear in
mind this list has no particular expertise on Glassfish nor on
Websphere, so we might tell you (gasp) to go ask for product-specific
help from one of those communities.

Post by b***@commcity.ch
I don't know what is going on behind the scenes, hence I need a little
help to resolve the issue. Being sent from one to the next is not exactly
the expected kind of help.

Perhaps you need to adjust your "expectations" entirely. No one here
is getting paid to help you. We are all volunteers. Feel free to reply
more & we're happy to help but seriously, lose the attitude.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@maven.apache.org
For additional commands, e-mail: users-***@maven.apache.org

[b***@commcity.ch]

The outcome of the announced tests are:

On working with eclipse Kepler, not having any WAS-Plugin installed the
classes compiled by maven, either started from command line or through
m2e-wtp are correct, the resulting ear can be deployed on the WebSphere
App-Server and runs without error!

I hope, I must not emphases, absolutely no changes have been applied to
the checked out modules. Hence, the problem within the june installation
is not due to any odd configuration of maven.

This means, I can deploy valid ear's to the nexus maven repository! This
are the good news!

But the situation is not satisfying, as within eclipse-Kepler I can not
debug through a server plugin, and within eclipse-June, I can not deploy
any maven build!

If you tell me now, this is not a maven issue, I admit you may be right!
But my question, what the heck is going on behind the scene is still open
and must be allowed.

Could this be a WAS-Plugin issue? You being closer to maven maybe can
answer this question!




From: ***@commcity.ch
To: "Maven Users List" <***@maven.apache.org>
Date: 06.11.2013 09:34
Subject: Re: Imports of required classes have classname only
without package path within the class compiled by maven



Hi,
this is much better.

Based on my actual knowledge, yes I believe it must have a relation with
the Juno Version of eclipse, but I don't know how and why.

The differences between the two flavors of project are minimal and due to
the differences of App-Server and Databases used. If Java would have
conditional compilation the differences could be handled much easier by
this. For instance the server and jsf-implementation related differences
requires to have two web.xml files, checked out from separated branches of

svn. Or the login / logout methods within one class differs slightly due
to the different implementations of the servers, etc. I hardly believe
those differences being the cause of the troubles.

Fact is: The outcome of the maven compilation is the same for both cases.
Either started from the command line or started within the juno IDE.

I'm actually checking out the project into an entirely new kepler SP1
workplace, from where I'll try a build from the command line. I'll tell
you the outcome.

I'll try this before I installing m2e-wtp. Hence, I'll just use subclipse
to checkout the project from the svn server. I choose this approach,
instead of svn tortoise for instance, to be able to analyze what will
happen after installation of the m2e-wtp-Plugin.

Unfortunately the WAS-Plugin is still not available for Kepler, which
means I must still stick to juno if I want debug the code for WebSphere.





From: Wayne Fay <***@gmail.com>
To: Maven Users List <***@maven.apache.org>
Date: 05.11.2013 07:47
Subject: Re: Imports of required classes have classname only

Post by b***@commcity.ch
Sorry this answer is not helpful.

If you are ever unsatisfied with the advice that you receive from this
list, you are immediately entitled to a FULL REFUND. Calling people
out is more likely to get you added to their ban/ignore list than
anything else. Would you simply prefer that your emails are ignored if
no one can provide an immediate and concise answer to your problems?

Post by b***@commcity.ch
m2e tells me, it's not their problem, it's maven and you tell me the
opposite!

I said that you would need to talk to the m2e people about m2e
problems and that this list could help you with command-line Maven
only. That was and still is true.

Post by b***@commcity.ch
I think it's neither IBM, because changing the Glassfish project to use
the IBM J9 VM instead of oracle jdk 1.6.0_45 compiles to correct classes,
as with the oracle jdk!

...

Post by b***@commcity.ch
In opposition compiling within the WebSphere project on the command line
mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
doesn't show any Error and the classes are defective independent of the
JAVA_HOME setting, either IBM J9 VM or the oracle jdk!

It sounds to me like the one constant in all your failures is your
WebSphere project itself. You said the following:
"glassfish project" + ibm j9 vm = works
"glassfish project" + oracle jdk 1.6.0_45 = works
"websphere project" + any jvm = fails

If this is true, it seems like you will need to provide a lot more
information (and maybe even a small sample project) about the
Websphere project you are attempting to build.

Post by b***@commcity.ch
${version.maven-compiler-plugin}</version>

...

Post by b***@commcity.ch
${version.java.jdk}</source>

...

Post by b***@commcity.ch
"${env.WAS8_HOME}/java/bin/javac.exe"</executable>

Replace all those ${...} with hardcoded values for testing. Once it is
working properly, you can go back and use the variables instead.

Post by b***@commcity.ch
The environment variable has been verified and is correct. Confirmed by
[DEBUG] properties used {env.INTEL64_HOME=C:\Program Files\Intel,

This is not especially useful. Far more useful is to look at the
compiler plugin output lines (emitted with -X) that show you the exact
command that was used when calling your compiler. I said this in my

Post by b***@commcity.ch

Maven (command line) simply calls out to the JDK installed on your
system. You can use "mvn -X" to see the actual command that Maven uses
to call javac. If you are experiencing problems with the output of

By looking at & copy/pasting the output, you can do your own
compilation of classes etc in the various modules and swap out the
JDK/javac being used and all manner of things. If you did this, you
would probably find the one thing which consistently breaks your
builds which would clue you into the root cause of your current
troubles.

Post by b***@commcity.ch
But the compiled classes are not usable at all. Of course, it's a
multi-module project, which may be the origin of the problem. I can only
say, it works with the glassfish configuration, but it don't with the
WebSphere configuration! It' worked for a while with WAS too but then it
stopped to work for an unknown reason.

What things are different between "the glassfish configuration" and
"the websphere configuration"? Can you enumerate that list? Bear in
mind this list has no particular expertise on Glassfish nor on
Websphere, so we might tell you (gasp) to go ask for product-specific
help from one of those communities.

Post by b***@commcity.ch
I don't know what is going on behind the scenes, hence I need a little
help to resolve the issue. Being sent from one to the next is not exactly
the expected kind of help.

Perhaps you need to adjust your "expectations" entirely. No one here
is getting paid to help you. We are all volunteers. Feel free to reply
more & we're happy to help but seriously, lose the attitude.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@maven.apache.org
For additional commands, e-mail: users-***@maven.apache.org

[Anders Hammar]

What WAS plugin for Eclipse are you talking about. The ones in Eclipse
marketplace should work with Kepler SR1 (v4.3.1) according to the info
there [1] [2]. They were just recently updated (Nov 1).

[1]
https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-developer-tools-eclipse-4x
[2]
https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-liberty-profile-developer-tools-eclipse-4x

/Anders

Post by b***@commcity.ch
On working with eclipse Kepler, not having any WAS-Plugin installed the
classes compiled by maven, either started from command line or through
m2e-wtp are correct, the resulting ear can be deployed on the WebSphere
App-Server and runs without error!
I hope, I must not emphases, absolutely no changes have been applied to
the checked out modules. Hence, the problem within the june installation
is not due to any odd configuration of maven.
This means, I can deploy valid ear's to the nexus maven repository! This
are the good news!
But the situation is not satisfying, as within eclipse-Kepler I can not
debug through a server plugin, and within eclipse-June, I can not deploy
any maven build!
If you tell me now, this is not a maven issue, I admit you may be right!
But my question, what the heck is going on behind the scene is still open
and must be allowed.
Could this be a WAS-Plugin issue? You being closer to maven maybe can
answer this question!
Date: 06.11.2013 09:34
Subject: Re: Imports of required classes have classname only
without package path within the class compiled by maven
Hi,
this is much better.
Based on my actual knowledge, yes I believe it must have a relation with
the Juno Version of eclipse, but I don't know how and why.
The differences between the two flavors of project are minimal and due to
the differences of App-Server and Databases used. If Java would have
conditional compilation the differences could be handled much easier by
this. For instance the server and jsf-implementation related differences
requires to have two web.xml files, checked out from separated branches of
svn. Or the login / logout methods within one class differs slightly due
to the different implementations of the servers, etc. I hardly believe
those differences being the cause of the troubles.
Fact is: The outcome of the maven compilation is the same for both cases.
Either started from the command line or started within the juno IDE.
I'm actually checking out the project into an entirely new kepler SP1
workplace, from where I'll try a build from the command line. I'll tell
you the outcome.
I'll try this before I installing m2e-wtp. Hence, I'll just use subclipse
to checkout the project from the svn server. I choose this approach,
instead of svn tortoise for instance, to be able to analyze what will
happen after installation of the m2e-wtp-Plugin.
Unfortunately the WAS-Plugin is still not available for Kepler, which
means I must still stick to juno if I want debug the code for WebSphere.
Date: 05.11.2013 07:47
Subject: Re: Imports of required classes have classname only

Post by b***@commcity.ch
Sorry this answer is not helpful.

If you are ever unsatisfied with the advice that you receive from this
list, you are immediately entitled to a FULL REFUND. Calling people
out is more likely to get you added to their ban/ignore list than
anything else. Would you simply prefer that your emails are ignored if
no one can provide an immediate and concise answer to your problems?

Post by b***@commcity.ch
m2e tells me, it's not their problem, it's maven and you tell me the
opposite!

I said that you would need to talk to the m2e people about m2e
problems and that this list could help you with command-line Maven
only. That was and still is true.

Post by b***@commcity.ch
I think it's neither IBM, because changing the Glassfish project to use
the IBM J9 VM instead of oracle jdk 1.6.0_45 compiles to correct

classes,

Post by b***@commcity.ch
as with the oracle jdk!

...

Post by b***@commcity.ch
In opposition compiling within the WebSphere project on the command line
mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
doesn't show any Error and the classes are defective independent of the
JAVA_HOME setting, either IBM J9 VM or the oracle jdk!

It sounds to me like the one constant in all your failures is your
"glassfish project" + ibm j9 vm = works
"glassfish project" + oracle jdk 1.6.0_45 = works
"websphere project" + any jvm = fails
If this is true, it seems like you will need to provide a lot more
information (and maybe even a small sample project) about the
Websphere project you are attempting to build.

Post by b***@commcity.ch
${version.maven-compiler-plugin}</version>

...

Post by b***@commcity.ch
${version.java.jdk}</source>

...

Post by b***@commcity.ch
"${env.WAS8_HOME}/java/bin/javac.exe"</executable>

Replace all those ${...} with hardcoded values for testing. Once it is
working properly, you can go back and use the variables instead.

Post by b***@commcity.ch
The environment variable has been verified and is correct. Confirmed by
[DEBUG] properties used {env.INTEL64_HOME=C:\Program Files\Intel,

This is not especially useful. Far more useful is to look at the
compiler plugin output lines (emitted with -X) that show you the exact
command that was used when calling your compiler. I said this in my

Post by b***@commcity.ch

Maven (command line) simply calls out to the JDK installed on your
system. You can use "mvn -X" to see the actual command that Maven uses
to call javac. If you are experiencing problems with the output of

By looking at & copy/pasting the output, you can do your own
compilation of classes etc in the various modules and swap out the
JDK/javac being used and all manner of things. If you did this, you
would probably find the one thing which consistently breaks your
builds which would clue you into the root cause of your current
troubles.

Post by b***@commcity.ch
But the compiled classes are not usable at all. Of course, it's a
multi-module project, which may be the origin of the problem. I can only
say, it works with the glassfish configuration, but it don't with the
WebSphere configuration! It' worked for a while with WAS too but then it
stopped to work for an unknown reason.

What things are different between "the glassfish configuration" and
"the websphere configuration"? Can you enumerate that list? Bear in
mind this list has no particular expertise on Glassfish nor on
Websphere, so we might tell you (gasp) to go ask for product-specific
help from one of those communities.

Post by b***@commcity.ch
I don't know what is going on behind the scenes, hence I need a little
help to resolve the issue. Being sent from one to the next is not

exactly

Post by b***@commcity.ch
the expected kind of help.

Perhaps you need to adjust your "expectations" entirely. No one here
is getting paid to help you. We are all volunteers. Feel free to reply
more & we're happy to help but seriously, lose the attitude.
Wayne
---------------------------------------------------------------------

[b***@commcity.ch]

Exactly those you sent me the URL. I haven't seen yet. Hopefully they work
with WAS 8.5.5.0! As far as I know, 8.5.5.1 shall be available on November
11 only! I just searched for an update with the Installation Manager, but
nothing seams to be available.

I'll try in any case now. Thanks for the hint.




From: Anders Hammar <***@hammar.net>
To: Maven Users List <***@maven.apache.org>
Date: 06.11.2013 15:17
Subject: Re: Imports of required classes have classname only
without package path within the class compiled by maven
Sent by: ***@gmail.com



What WAS plugin for Eclipse are you talking about. The ones in Eclipse
marketplace should work with Kepler SR1 (v4.3.1) according to the info
there [1] [2]. They were just recently updated (Nov 1).

[1]
https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-developer-tools-eclipse-4x

[2]
https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-liberty-profile-developer-tools-eclipse-4x


/Anders

Post by b***@commcity.ch
On working with eclipse Kepler, not having any WAS-Plugin installed the
classes compiled by maven, either started from command line or through
m2e-wtp are correct, the resulting ear can be deployed on the WebSphere
App-Server and runs without error!
I hope, I must not emphases, absolutely no changes have been applied to
the checked out modules. Hence, the problem within the june installation
is not due to any odd configuration of maven.
This means, I can deploy valid ear's to the nexus maven repository! This
are the good news!
But the situation is not satisfying, as within eclipse-Kepler I can not
debug through a server plugin, and within eclipse-June, I can not deploy
any maven build!
If you tell me now, this is not a maven issue, I admit you may be right!
But my question, what the heck is going on behind the scene is still open
and must be allowed.
Could this be a WAS-Plugin issue? You being closer to maven maybe can
answer this question!
Date: 06.11.2013 09:34
Subject: Re: Imports of required classes have classname only
without package path within the class compiled by maven
Hi,
this is much better.
Based on my actual knowledge, yes I believe it must have a relation with
the Juno Version of eclipse, but I don't know how and why.
The differences between the two flavors of project are minimal and due to
the differences of App-Server and Databases used. If Java would have
conditional compilation the differences could be handled much easier by
this. For instance the server and jsf-implementation related

differences

Post by b***@commcity.ch
requires to have two web.xml files, checked out from separated branches of
svn. Or the login / logout methods within one class differs slightly due
to the different implementations of the servers, etc. I hardly believe
those differences being the cause of the troubles.
Fact is: The outcome of the maven compilation is the same for both cases.
Either started from the command line or started within the juno IDE.
I'm actually checking out the project into an entirely new kepler SP1
workplace, from where I'll try a build from the command line. I'll tell
you the outcome.
I'll try this before I installing m2e-wtp. Hence, I'll just use subclipse
to checkout the project from the svn server. I choose this approach,
instead of svn tortoise for instance, to be able to analyze what will
happen after installation of the m2e-wtp-Plugin.
Unfortunately the WAS-Plugin is still not available for Kepler, which
means I must still stick to juno if I want debug the code for WebSphere.
Date: 05.11.2013 07:47
Subject: Re: Imports of required classes have classname only

Post by b***@commcity.ch
Sorry this answer is not helpful.

If you are ever unsatisfied with the advice that you receive from this
list, you are immediately entitled to a FULL REFUND. Calling people
out is more likely to get you added to their ban/ignore list than
anything else. Would you simply prefer that your emails are ignored if
no one can provide an immediate and concise answer to your problems?

Post by b***@commcity.ch
m2e tells me, it's not their problem, it's maven and you tell me the
opposite!

I said that you would need to talk to the m2e people about m2e
problems and that this list could help you with command-line Maven
only. That was and still is true.

Post by b***@commcity.ch
I think it's neither IBM, because changing the Glassfish project to use
the IBM J9 VM instead of oracle jdk 1.6.0_45 compiles to correct

classes,

Post by b***@commcity.ch
as with the oracle jdk!

...

Post by b***@commcity.ch
In opposition compiling within the WebSphere project on the command line
mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
doesn't show any Error and the classes are defective independent of the
JAVA_HOME setting, either IBM J9 VM or the oracle jdk!

It sounds to me like the one constant in all your failures is your
"glassfish project" + ibm j9 vm = works
"glassfish project" + oracle jdk 1.6.0_45 = works
"websphere project" + any jvm = fails
If this is true, it seems like you will need to provide a lot more
information (and maybe even a small sample project) about the
Websphere project you are attempting to build.

Post by b***@commcity.ch
${version.maven-compiler-plugin}</version>

...

Post by b***@commcity.ch
${version.java.jdk}</source>

...

Post by b***@commcity.ch
"${env.WAS8_HOME}/java/bin/javac.exe"</executable>

Replace all those ${...} with hardcoded values for testing. Once it is
working properly, you can go back and use the variables instead.

Post by b***@commcity.ch
The environment variable has been verified and is correct. Confirmed by
[DEBUG] properties used {env.INTEL64_HOME=C:\Program Files\Intel,

This is not especially useful. Far more useful is to look at the
compiler plugin output lines (emitted with -X) that show you the exact
command that was used when calling your compiler. I said this in my

Post by b***@commcity.ch

Maven (command line) simply calls out to the JDK installed on your
system. You can use "mvn -X" to see the actual command that Maven uses
to call javac. If you are experiencing problems with the output of

By looking at & copy/pasting the output, you can do your own
compilation of classes etc in the various modules and swap out the
JDK/javac being used and all manner of things. If you did this, you
would probably find the one thing which consistently breaks your
builds which would clue you into the root cause of your current
troubles.

Post by b***@commcity.ch
But the compiled classes are not usable at all. Of course, it's a
multi-module project, which may be the origin of the problem. I can only
say, it works with the glassfish configuration, but it don't with the
WebSphere configuration! It' worked for a while with WAS too but then it
stopped to work for an unknown reason.

What things are different between "the glassfish configuration" and
"the websphere configuration"? Can you enumerate that list? Bear in
mind this list has no particular expertise on Glassfish nor on
Websphere, so we might tell you (gasp) to go ask for product-specific
help from one of those communities.

Post by b***@commcity.ch
I don't know what is going on behind the scenes, hence I need a little
help to resolve the issue. Being sent from one to the next is not

exactly

Post by b***@commcity.ch
the expected kind of help.

Perhaps you need to adjust your "expectations" entirely. No one here
is getting paid to help you. We are all volunteers. Feel free to reply
more & we're happy to help but seriously, lose the attitude.
Wayne
---------------------------------------------------------------------

[Anders Hammar]

They should work with WAS 8.5.5.x.

Here's the IBM site with the links:
https://www.ibmdw.net/wasdev/downloads/websphere-application-server-developer-tools-v8-5-5/

/Anders

Post by b***@commcity.ch
Exactly those you sent me the URL. I haven't seen yet. Hopefully they work
with WAS 8.5.5.0! As far as I know, 8.5.5.1 shall be available on November
11 only! I just searched for an update with the Installation Manager, but
nothing seams to be available.
I'll try in any case now. Thanks for the hint.
Date: 06.11.2013 15:17
Subject: Re: Imports of required classes have classname only
without package path within the class compiled by maven
What WAS plugin for Eclipse are you talking about. The ones in Eclipse
marketplace should work with Kepler SR1 (v4.3.1) according to the info
there [1] [2]. They were just recently updated (Nov 1).
[1]
https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-developer-tools-eclipse-4x
[2]
https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-liberty-profile-developer-tools-eclipse-4x
/Anders

Post by b***@commcity.ch
On working with eclipse Kepler, not having any WAS-Plugin installed the
classes compiled by maven, either started from command line or through
m2e-wtp are correct, the resulting ear can be deployed on the WebSphere
App-Server and runs without error!
I hope, I must not emphases, absolutely no changes have been applied to
the checked out modules. Hence, the problem within the june installation
is not due to any odd configuration of maven.
This means, I can deploy valid ear's to the nexus maven repository! This
are the good news!
But the situation is not satisfying, as within eclipse-Kepler I can not
debug through a server plugin, and within eclipse-June, I can not deploy
any maven build!
If you tell me now, this is not a maven issue, I admit you may be right!
But my question, what the heck is going on behind the scene is still

open

Post by b***@commcity.ch
and must be allowed.
Could this be a WAS-Plugin issue? You being closer to maven maybe can
answer this question!
Date: 06.11.2013 09:34
Subject: Re: Imports of required classes have classname only
without package path within the class compiled by maven
Hi,
this is much better.
Based on my actual knowledge, yes I believe it must have a relation with
the Juno Version of eclipse, but I don't know how and why.
The differences between the two flavors of project are minimal and due

to

Post by b***@commcity.ch
the differences of App-Server and Databases used. If Java would have
conditional compilation the differences could be handled much easier by
this. For instance the server and jsf-implementation related

differences

Post by b***@commcity.ch
requires to have two web.xml files, checked out from separated branches

of

Post by b***@commcity.ch
svn. Or the login / logout methods within one class differs slightly due
to the different implementations of the servers, etc. I hardly believe
those differences being the cause of the troubles.
Fact is: The outcome of the maven compilation is the same for both

cases.

Post by b***@commcity.ch
Either started from the command line or started within the juno IDE.
I'm actually checking out the project into an entirely new kepler SP1
workplace, from where I'll try a build from the command line. I'll tell
you the outcome.
I'll try this before I installing m2e-wtp. Hence, I'll just use

subclipse

Post by b***@commcity.ch
to checkout the project from the svn server. I choose this approach,
instead of svn tortoise for instance, to be able to analyze what will
happen after installation of the m2e-wtp-Plugin.
Unfortunately the WAS-Plugin is still not available for Kepler, which
means I must still stick to juno if I want debug the code for WebSphere.
Date: 05.11.2013 07:47
Subject: Re: Imports of required classes have classname only

Post by b***@commcity.ch
Sorry this answer is not helpful.

If you are ever unsatisfied with the advice that you receive from this
list, you are immediately entitled to a FULL REFUND. Calling people
out is more likely to get you added to their ban/ignore list than
anything else. Would you simply prefer that your emails are ignored if
no one can provide an immediate and concise answer to your problems?

Post by b***@commcity.ch
m2e tells me, it's not their problem, it's maven and you tell me the
opposite!

I said that you would need to talk to the m2e people about m2e
problems and that this list could help you with command-line Maven
only. That was and still is true.

Post by b***@commcity.ch
I think it's neither IBM, because changing the Glassfish project to

use

Post by b***@commcity.ch

Post by b***@commcity.ch
the IBM J9 VM instead of oracle jdk 1.6.0_45 compiles to correct

classes,

Post by b***@commcity.ch
as with the oracle jdk!

...

Post by b***@commcity.ch
In opposition compiling within the WebSphere project on the command

line

Post by b***@commcity.ch

Post by b***@commcity.ch
mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
doesn't show any Error and the classes are defective independent of

the

Post by b***@commcity.ch

Post by b***@commcity.ch
JAVA_HOME setting, either IBM J9 VM or the oracle jdk!

It sounds to me like the one constant in all your failures is your
"glassfish project" + ibm j9 vm = works
"glassfish project" + oracle jdk 1.6.0_45 = works
"websphere project" + any jvm = fails
If this is true, it seems like you will need to provide a lot more
information (and maybe even a small sample project) about the
Websphere project you are attempting to build.

Post by b***@commcity.ch
${version.maven-compiler-plugin}</version>

...

Post by b***@commcity.ch
${version.java.jdk}</source>

...

Post by b***@commcity.ch
"${env.WAS8_HOME}/java/bin/javac.exe"</executable>

Replace all those ${...} with hardcoded values for testing. Once it is
working properly, you can go back and use the variables instead.

Post by b***@commcity.ch
The environment variable has been verified and is correct. Confirmed

by

Post by b***@commcity.ch

Post by b***@commcity.ch
[DEBUG] properties used {env.INTEL64_HOME=C:\Program Files\Intel,

This is not especially useful. Far more useful is to look at the
compiler plugin output lines (emitted with -X) that show you the exact
command that was used when calling your compiler. I said this in my

Post by b***@commcity.ch

Maven (command line) simply calls out to the JDK installed on your
system. You can use "mvn -X" to see the actual command that Maven

uses

Post by b***@commcity.ch

Post by b***@commcity.ch

to call javac. If you are experiencing problems with the output of

By looking at & copy/pasting the output, you can do your own
compilation of classes etc in the various modules and swap out the
JDK/javac being used and all manner of things. If you did this, you
would probably find the one thing which consistently breaks your
builds which would clue you into the root cause of your current
troubles.

Post by b***@commcity.ch
But the compiled classes are not usable at all. Of course, it's a
multi-module project, which may be the origin of the problem. I can

only

Post by b***@commcity.ch

Post by b***@commcity.ch
say, it works with the glassfish configuration, but it don't with the
WebSphere configuration! It' worked for a while with WAS too but then

it

Post by b***@commcity.ch

Post by b***@commcity.ch
stopped to work for an unknown reason.

What things are different between "the glassfish configuration" and
"the websphere configuration"? Can you enumerate that list? Bear in
mind this list has no particular expertise on Glassfish nor on
Websphere, so we might tell you (gasp) to go ask for product-specific
help from one of those communities.

Post by b***@commcity.ch
I don't know what is going on behind the scenes, hence I need a little
help to resolve the issue. Being sent from one to the next is not

exactly

Post by b***@commcity.ch
the expected kind of help.

Perhaps you need to adjust your "expectations" entirely. No one here
is getting paid to help you. We are all volunteers. Feel free to reply
more & we're happy to help but seriously, lose the attitude.
Wayne
---------------------------------------------------------------------

[b***@commcity.ch]

As announced, here a little summary about the experiences with the
WebeSphere developer tools for eclipse 4.

Positive:
It works! Eclipse generates a valid build, as well as does maven! and even
debugging is possible.

Negative:
The marketplace seems to have a problem. At least I was unable to install
those WAS-plugins from the marketplace. It required to download the zip
and install the app from the local zip. Trying to search for updates
neither works. Apparently the url does not point to a site from which
updates could be downloaded or versions verified.

I had some trouble with xml files validation during an eternity. On
pointing to local schema.xsd or disabling validation the problem could be
solved so far.
I observed helper files from the build being copied into the war and jar
files. I.e. org.codehaus.plexus.compiler.javac.JavacCompiler*arguments and
javac.bat.
This is new and should not be the case, though these files don’t hurt!
Question:
With this new installation I got 2 new Warnings for which I have not found
the way to eliminate them:
The Maven standard project settings are not set for the workspace.
The target runtime server dependencies should be declared in the POM file.
Any hint is welcome.




From: ***@commcity.ch
To: "Maven Users List" <***@maven.apache.org>
Date: 06.11.2013 15:32
Subject: Re: Imports of required classes have classname only
without package path within the class compiled by maven



Exactly those you sent me the URL. I haven't seen yet. Hopefully they work

with WAS 8.5.5.0! As far as I know, 8.5.5.1 shall be available on November

11 only! I just searched for an update with the Installation Manager, but
nothing seams to be available.

I'll try in any case now. Thanks for the hint.




From: Anders Hammar <***@hammar.net>
To: Maven Users List <***@maven.apache.org>
Date: 06.11.2013 15:17
Subject: Re: Imports of required classes have classname only
without package path within the class compiled by maven
Sent by: ***@gmail.com



What WAS plugin for Eclipse are you talking about. The ones in Eclipse
marketplace should work with Kepler SR1 (v4.3.1) according to the info
there [1] [2]. They were just recently updated (Nov 1).

[1]
https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-developer-tools-eclipse-4x


[2]
https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-liberty-profile-developer-tools-eclipse-4x



/Anders

Post by b***@commcity.ch
On working with eclipse Kepler, not having any WAS-Plugin installed the
classes compiled by maven, either started from command line or through
m2e-wtp are correct, the resulting ear can be deployed on the WebSphere
App-Server and runs without error!
I hope, I must not emphases, absolutely no changes have been applied to
the checked out modules. Hence, the problem within the june installation
is not due to any odd configuration of maven.
This means, I can deploy valid ear's to the nexus maven repository! This
are the good news!
But the situation is not satisfying, as within eclipse-Kepler I can not
debug through a server plugin, and within eclipse-June, I can not deploy
any maven build!
If you tell me now, this is not a maven issue, I admit you may be right!
But my question, what the heck is going on behind the scene is still open
and must be allowed.
Could this be a WAS-Plugin issue? You being closer to maven maybe can
answer this question!
Date: 06.11.2013 09:34
Subject: Re: Imports of required classes have classname only
without package path within the class compiled by maven
Hi,
this is much better.
Based on my actual knowledge, yes I believe it must have a relation with
the Juno Version of eclipse, but I don't know how and why.
The differences between the two flavors of project are minimal and due to
the differences of App-Server and Databases used. If Java would have
conditional compilation the differences could be handled much easier by
this. For instance the server and jsf-implementation related

differences

Post by b***@commcity.ch
requires to have two web.xml files, checked out from separated branches of
svn. Or the login / logout methods within one class differs slightly due
to the different implementations of the servers, etc. I hardly believe
those differences being the cause of the troubles.
Fact is: The outcome of the maven compilation is the same for both cases.
Either started from the command line or started within the juno IDE.
I'm actually checking out the project into an entirely new kepler SP1
workplace, from where I'll try a build from the command line. I'll tell
you the outcome.
I'll try this before I installing m2e-wtp. Hence, I'll just use subclipse
to checkout the project from the svn server. I choose this approach,
instead of svn tortoise for instance, to be able to analyze what will
happen after installation of the m2e-wtp-Plugin.
Unfortunately the WAS-Plugin is still not available for Kepler, which
means I must still stick to juno if I want debug the code for WebSphere.
Date: 05.11.2013 07:47
Subject: Re: Imports of required classes have classname only

Post by b***@commcity.ch
Sorry this answer is not helpful.

If you are ever unsatisfied with the advice that you receive from this
list, you are immediately entitled to a FULL REFUND. Calling people
out is more likely to get you added to their ban/ignore list than
anything else. Would you simply prefer that your emails are ignored if
no one can provide an immediate and concise answer to your problems?

Post by b***@commcity.ch
m2e tells me, it's not their problem, it's maven and you tell me the
opposite!

I said that you would need to talk to the m2e people about m2e
problems and that this list could help you with command-line Maven
only. That was and still is true.

Post by b***@commcity.ch
I think it's neither IBM, because changing the Glassfish project to use
the IBM J9 VM instead of oracle jdk 1.6.0_45 compiles to correct

classes,

Post by b***@commcity.ch
as with the oracle jdk!

...

Post by b***@commcity.ch
In opposition compiling within the WebSphere project on the command line
mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
doesn't show any Error and the classes are defective independent of the
JAVA_HOME setting, either IBM J9 VM or the oracle jdk!

It sounds to me like the one constant in all your failures is your
"glassfish project" + ibm j9 vm = works
"glassfish project" + oracle jdk 1.6.0_45 = works
"websphere project" + any jvm = fails
If this is true, it seems like you will need to provide a lot more
information (and maybe even a small sample project) about the
Websphere project you are attempting to build.

Post by b***@commcity.ch
${version.maven-compiler-plugin}</version>

...

Post by b***@commcity.ch
${version.java.jdk}</source>

...

Post by b***@commcity.ch
"${env.WAS8_HOME}/java/bin/javac.exe"</executable>

Replace all those ${...} with hardcoded values for testing. Once it is
working properly, you can go back and use the variables instead.

Post by b***@commcity.ch
The environment variable has been verified and is correct. Confirmed by
[DEBUG] properties used {env.INTEL64_HOME=C:\Program Files\Intel,

This is not especially useful. Far more useful is to look at the
compiler plugin output lines (emitted with -X) that show you the exact
command that was used when calling your compiler. I said this in my

Post by b***@commcity.ch

Maven (command line) simply calls out to the JDK installed on your
system. You can use "mvn -X" to see the actual command that Maven uses
to call javac. If you are experiencing problems with the output of

By looking at & copy/pasting the output, you can do your own
compilation of classes etc in the various modules and swap out the
JDK/javac being used and all manner of things. If you did this, you
would probably find the one thing which consistently breaks your
builds which would clue you into the root cause of your current
troubles.

Post by b***@commcity.ch
But the compiled classes are not usable at all. Of course, it's a
multi-module project, which may be the origin of the problem. I can only
say, it works with the glassfish configuration, but it don't with the
WebSphere configuration! It' worked for a while with WAS too but then it
stopped to work for an unknown reason.

What things are different between "the glassfish configuration" and
"the websphere configuration"? Can you enumerate that list? Bear in
mind this list has no particular expertise on Glassfish nor on
Websphere, so we might tell you (gasp) to go ask for product-specific
help from one of those communities.

Post by b***@commcity.ch
I don't know what is going on behind the scenes, hence I need a little
help to resolve the issue. Being sent from one to the next is not

exactly

Post by b***@commcity.ch
the expected kind of help.

Perhaps you need to adjust your "expectations" entirely. No one here
is getting paid to help you. We are all volunteers. Feel free to reply
more & we're happy to help but seriously, lose the attitude.
Wayne
---------------------------------------------------------------------