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 On Wed, Nov 6, 2013 at 3:28 PM, <[email protected]> wrote: > 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] > > > > > > > > > >
