maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Imports of required classes have classname only without package path within the class compiled by maven
Date Wed, 06 Nov 2013 14:28:46 GMT
Exactly those you sent me the URL. I haven't seen yet. Hopefully they work 
with WAS! As far as I know, 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 <>
To:     Maven Users List <>
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:

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




On Wed, Nov 6, 2013 at 3:06 PM, <> wrote:

> 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 
> and must be allowed.
> Could this be a WAS-Plugin issue? You being closer to maven maybe can
> answer this question!
> From:
> To:     "Maven Users List" <>
> 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 
> 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 
> requires to have two web.xml files, checked out from separated branches 
> 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 
> 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 
> 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 <>
> To:     Maven Users List <>
> Date:   05.11.2013 07:47
> Subject:        Re: Imports of required classes have classname only
> without package path within the class compiled by maven @Wayne Fay
> > 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 
> > 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 
> > with:
> > mvn -X clean package -Dmaven.test.skip=true -Pdefault-profile
> > doesn't show any Error and the classes are defective independent of 
> > 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 
> > 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 
> >> 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.
> > 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 
> > 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 
> > 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.
> Wayne
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message