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: brandenber...@commcity.ch To: "Maven Users List" <users@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 <and...@hammar.net> To: Maven Users List <users@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: anders.g.ham...@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 On Wed, Nov 6, 2013 at 3:06 PM, <brandenber...@commcity.ch> 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: brandenber...@commcity.ch > To: "Maven Users List" <users@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 <wayne...@gmail.com> > To: Maven Users List <users@maven.apache.org> > 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > >
