strong texti have a very simple eclipse 3.8-based rcp application with an .aj file. i also have AJDT 2.2.1 installed, and have the following four entries in my build.properties:
javacSource=1.6
javacTarget=1.6
compilerAdapter=org.eclipse.ajdt.core.ant.AJDT_AjcCompilerAdapter
sourceFileExtensions=*.java, *.aj
i am using a headless build approach via Ant, and it has been working like a charm, AJDT and all, while using java 1.6. but once i upgraded from java 1.6 to 1.7, and changed the two aforementioned build.properties entries' -- javacSource and javacTarget -- values from 1.6 to 1.7, i got a boat-load of build errors, all with the following suffix:
... are only available if source level is 1.5 or greater
setting build.properties' javacSource back to 1.6, while leaving javacTarget at 1.7 works. or if i were to comment out the two AJDT-specific entries from my build.properties, while leaving javacSource and javacTarget values at 1.7. the build completes just fine as well. so my guess is that AJDT compiler is somehow the culprit. the question is why and what can be done to resolve it.
thank you for your time!!!
It sounds like one of two things:
Your AJDT installed does not have an AspectJ in it that is compatible with Java 1.7. What AspectJ version are you building with? Note that this aspectj version may be different from the one in your target platform.
You are not correctly specifying the Java source/target version in a way that AspectJ can recognize. How are you specifying the Java source/target version?
Related
I have some projects in my eclipse Luna that are based on Java 1.6 and I am trying to learn the latest spring boot which uses Java 1.8 , I am learning spring boot on spring tool suite which is based out of eclipse ,I tried installing Java 1.8 in my system and I have successful install both 1.6 and 1.8 Java in my system but when I try to open Spring tool suite it says JDK version should be 1.8 or higher I know I have the classpath set as 1.6 but is there anyway we can set the classpath 1.6 for eclipse Luna and Java 1.8 classpath for spring tool suite because I constantly change over projects as because Java 1.6 is my production environment in Java 1.8 is something like a test where I am trying to learn spring tool suite.
Is there any way we can achieve this without having to change the classpath everytime I Switch between spring tool Suite and eclipse Luna
The first thing to understand is that Eclipse itself requires a JRE to run (preferably a JDK), and that JRE can be different than the one that your projects in Eclipse are configured to use - they are intentionally separate.
To specify the JRE that Eclipse itself runs in, you should specify it in eclipse.ini. Read that page carefully, the format is very particular. Once you've done that, your system classpath or JAVA_HOME or PATH will not matter, Eclipse prefers its own ini settings.
With that done, the default JRE/JDK used for your projects in Eclipse will be the same as the one Eclipse itself is running in. But that's only the default, you can add more JRE/JDKs and configure individual projects to use them.
The point is, each instance of Eclipse can be configured to run in a particular JRE/JDK you have on your system (although there's really no reason not to use the latest for running all Eclipse instances), and then within each Eclipse instance, each project can be configured to use a specific JRE/JDK (which may or may not be the same one that that Eclipse instance is running in).
For example, you should probably configure both Eclipse Luna and STS to use the JDK 8 you have, via their .ini files. Then in Luna you can add a JRE config for JDK 1.6 on your system and set projects to use that one. The projects don't have to use the same JRE/JDK that Eclipse itself is running in.
I have the task to do some work on our GWT 2.2 code base with
the GWT Config, etc, used, is long gone. And I must use Eclipse Kepler.
Does current GWT provide backward compatability that far?
Any thoughts?
The version of the Eclipse plugin is independent of the version of the SDK you use in your project. You can use the newest plugin with GWT projects that needs older versions of the SDK.
You have to set this up in the project properties.
While I can just try and run it and see if it fails I may not know if some internals will fail at inopportune times does anyone know if specific versions of java or eclipse are needed?
I'm sure, no special version of Java nor Eclipse is needed. It needs Java 1.5 and some Eclipse Modeling components (such as EMF); but they are already installed with Xtext.
I am using STS based on eclipe 2.6.2 and there is a scala plugin for eclipse
http://www.assembla.com/wiki/show/scala-ide
but it is not compatible with STS.
Is there anything other plugin.
I mainly need it debug play framework scala projects.
The Eclipse IDE for Scala should work with STS. I just tried it with version 2.6.1.RELEASE (build id 201105041000).
Make sure you do not select JDT Weaving for Scala when installing the Scala plugin. The JDT weaving component is provided already by STS (albeit an older version). The Scala plugin comes with a newer version, that upsets the AspectJ plugin (included by STS).
Even easier, you can use the Dashboard view, 'Extensions' page. You can check the Scala IDE from there, and it correctly leaves out the JDT weaving plugin.
If you have any other issues, use the mailing list (scala-ide-user#googlegroups.com) or file a ticket.
We have a Java EE 5 project developed using Netbeans 6.7.1 with Glassfish v2.1. Trying to open this project with Netbeans 6.9.1 with Glassfish v3.1 there are many errors concerning missing types.
Is Java EE 6 backward compatible with Java EE 5?
The missing libraries generally revolve around:
javax.xml.rpc.ServiceException;
javax.xml.rpc.Stub;
org.jvnet.staxex.StreamingDataHandler;
com.sun.xml.ws.fault.SOAPFaultBuilder;
Any ideas?
[Update]
It seems that not all of the required libraries are being added to the classpath for a Glassfish 3.1 project automatically. The main missing jar is jaxrpc-api-osgi.jar under glasshfish3/glassfish/modules/. If I add this jar manually all the problems go away. Why would this be the case? Why isn't the jar added automatically as is done using NetBeans 6.7.1 with Glassfish 2.1?
[Update]
I managed to hunt down org.jvnet.staxex.StreamingDataHandler; and com.sun.xml.ws.fault.SOAPFaultBuilder; via:
com.sun.xml.internal.org.jvnet.staxex.StreamingDataHandler;
com.sun.xml.internal.ws.fault.SOAPFaultBuilder;
Looks like some package changing went on. Still, this doesn't fix my problem with javax.xml.rpc.Stub; and javax.xml.rpc.ServiceException; not being added to my classpath correctly. I don't feel it's right to add the jar manually.
Wulfgarpro
Nothing is ever completely backwards compatible, but having those classes not showing up at all is suspicious. At least the first two are definitely in Java EE/Java 6. If there were incompatibilities I'd expect something like parameter mismatches or methods not found.
First place I'd look is at the Netbeans project setup -- I'd bet a small amount of money that your classpath.search path doesn't include something you need.
javax.xml.rpc is present in both EE 5 and 6. So this can't be about API version incompatibility. There must be a problem with the way your Netbeans project is set up.
I fixed the problem by uninstalling all JDK, JRE, and NetBeans. Reinstalling, the issue was rectified.
WulfgarPro