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 <[email protected]> To: Maven Users List <[email protected]> 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: [email protected] 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 On Wed, Nov 6, 2013 at 3:06 PM, <[email protected]> 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 open > and must be allowed. > > Could this be a WAS-Plugin issue? You being closer to maven maybe can > answer this question! > > > > > From: [email protected] > To: "Maven Users List" <[email protected]> > 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 <[email protected]> > To: Maven Users List <[email protected]> > 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 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> > ... > > ${version.java.jdk}</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 > 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 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. > > Wayne > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > >
