maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wayne Fay <>
Subject Re: Imports of required classes have classname only without package path within the class compiled by maven @Wayne Fay
Date Mon, 04 Nov 2013 18:37:07 GMT
> 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?

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

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

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.

> ${version.maven-compiler-plugin}</version>
> ${}</source>
> "${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.

> The environment variable has been verified and is correct. Confirmed by
> the logged output:
> [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
first reply to you:

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

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

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message