Community
Participate
Working Groups
For some reason I keep getting this error message whenever I try to generate code from my models. I get the same problem when generating code from the Mylyn Builds model. I think I have checked everything and am pretty sure that the source level actually is 1.5 for all projects. I've also tried to close the project, open it again. Clean build everything etc.
See also this thread http://www.eclipse.org/forums/index.php/mv/msg/205082/656051/#msg_656051
Just to make sure I got everything right I checked out the code in question from git://github.com/turesheim/org.eclipse.mylyn.docs.git into a new, fresh workspace. The code could be repeatedly generated as expected. Even after restarting Eclipse.
This error is produced by JDT. It's only produced if the source with Java 5.0 annotations is compiled with 1.4 source compatibility. You'll find if you create your own class by hand, you'll have the same problem, so it's not like the generator is producing bad code... You'll need to check things like what's in your .classpath, what's in your MANIFESt.MF, ensure you have a 5.0 or higher JRE as your JRE, ensure that you global default for JDT is 5.0 or higher Sometimes PDE Tools->Update Classpath helps.
Thanks Ed. I finally got around to look at this again. For future reference: Make sure that "Execution Environments" are mapped to JREs. For some reason this was not the case for my workspace and once I mapped J2SE-1.5 to a compatible JRE the problem went away. Every other setting looked OK.
How do I verify the JDT? & where do I find PDE tools? This appears to be a problem with my workspace as it works fine in other workspaces. D/ (In reply to comment #4) > Thanks Ed. > > You'll need to check things like > > what's in your .classpath, > what's in your MANIFESt.MF, > ensure you have a 5.0 or higher JRE as your JRE, > ensure that you global default for JDT is 5.0 or higher > > Sometimes PDE Tools->Update Classpath helps.
You've edited your MANIFEST.MF and looked at Window->Preferences->Java->Installed JRES?
(In reply to comment #6) > You've edited your MANIFEST.MF and looked at > Window->Preferences->Java->Installed JRES? Yup. I did all this prior to even googling... Every setting I know of and anything I could find just greping and click around is Java1.6SE.
In the end, it's really a JDT question you're asking so if none of this helps (thought surely one of the cases must be the problem) then ask on the newcomers on platform newsgroup. Likely they'll point out the same things I've already done though...
(In reply to comment #8) > In the end, it's really a JDT question you're asking so if none of this helps > (thought surely one of the cases must be the problem) then ask on the newcomers > on platform newsgroup. Likely they'll point out the same things I've already > done though... Why does this only impact the emf gen model? All other compiling, running, debugging, etc works fine in eclipse.
Created attachment 201038 [details] My Installed JREs (In reply to comment #9) > (In reply to comment #8) > > In the end, it's really a JDT question you're asking so if none of this helps > > (thought surely one of the cases must be the problem) then ask on the newcomers > > on platform newsgroup. Likely they'll point out the same things I've already > > done though... > > Why does this only impact the emf gen model? All other compiling, running, > debugging, etc works fine in eclipse. .classpash. > <?xml version="1.0" encoding="UTF-8"?> > <classpath> > <classpathentry kind="src" path="src/main/java"/> > <classpathentry kind="src" output="target/test-classes" path="src/test/java"/> > <classpathentry kind="con" > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMT> ype/JavaSE-1.6"/> > <classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"> > <attributes> > <attribute name="org.eclipse.jst.component.nondependency" value=""/> > </attributes> > </classpathentry> > <classpathentry kind="con" path="org.eclipse.jst.j2ee.internal.module.container"/> > <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> > <classpathentry kind="output" path="target/classes"/> > </classpath> MANIFEST.MF > Manifest-Version: 1.0 > Bundle-ManifestVersion: 2 > Bundle-Name: %pluginName > Bundle-SymbolicName: dex-ui-model;singleton:=true > Bundle-Version: 1.0.0 > Bundle-ClassPath: . > Bundle-Vendor: %providerName > Bundle-Localization: plugin > Bundle-RequiredExecutionEnvironment: JavaSE-1.6 > Require-Bundle: org.eclipse.core.runtime, > org.eclipse.emf.ecore;visibility:=reexport > Bundle-ActivationPolicy: lazy > Export-Package: com.mckesson.dex.ui.model, > com.mckesson.dex.ui.model.impl, > com.mckesson.dex.ui.model.util See attachment for my JDT Settings
What does your MANIFEST.MF say? Does it have this? Bundle-RequiredExecutionEnvironment: J2SE-1.5 On that project's context menu, what do your Properties...->Java->Compiler->JDK Compliance tell you?
(In reply to comment #11) > What does your MANIFEST.MF say? Does it have this? > > Bundle-RequiredExecutionEnvironment: J2SE-1.5 > > On that project's context menu, what do your Properties...->Java->Compiler->JDK > Compliance tell you? Compliance Level: 1.6 My manifest is in my previous post, with the following value: Bundle-RequiredExecutionEnvironment: JavaSE-1.6
I'm not sure what to say. You have projects with a problem. It's a problem where JDT is complaining you can't use features of Java 5.0 because your project hasn't enabled that. You say it is enabled, but JDT isn't convinced. I can't reproduce anything like that and I don't have any other ideas what setting JDT might be looking at. Try creating a new project from scratch and copy over the files to that.
(In reply to comment #13) > I'm not sure what to say. You have projects with a problem. It's a problem > where JDT is complaining you can't use features of Java 5.0 because your > project hasn't enabled that. You say it is enabled, but JDT isn't convinced. > I can't reproduce anything like that and I don't have any other ideas what > setting JDT might be looking at. Try creating a new project from scratch and > copy over the files to that. I think it is workspace and not project related. Our project file is in svn and I have verified I have no changes, yet my co-worker can generate model just fine.
I see that Ed continues to abdicate responsibility on this bug, which I still keep running into after 2 years of working with EMF. Let's get something straight here: if the problem is with JDT then it does a *very* good job of pretending to still be working. After all, JDT can compile my code (containing generics and annotations). JDT can execute my code on the Java 1.6 VM setup in my workspace. JDT can show me the source code of JDK classes by navigating to them from my own project. Only EMF is in any doubt the 1.5ness of my project. I can merely speculate that something is going wrong with the way EMF asks JDT, or the way it processes the response. The only workaround I have found to the problem is to create a fresh workspace and import the offending project. Then it usually works. This suggests that there MUST be something wrong in the workspace, but I have no idea how it gets into this state nor how to get out of it.
Given I can't reproduce the problem, what can I possibly do to take responsibility?
For what it's worth. I thought I had it nailed (see comment #4), but now this one has crept up on me again, in a new project. I've checked my settings as usual, to no avail. Given my own experience and comments from others in this issue I'm convinced this is a real bug and should be reopened. It may very well be a JDT bug - in that case we should probably pull in someone from the JDT team to help get it fixed.
With the changes from https://bugs.eclipse.org/bugs/show_bug.cgi?id=308069 the GenModel's compliance level setting should be used so as of EMF 2.8, I imagine you won't ever run into this problem. *** This bug has been marked as a duplicate of bug 308069 ***
Thanks Ed, Just tested with Eclipse 4.2 and EMF 2.8 and it looks good. EMF 2.8 cannot be installed on Eclipse 3.7 by the way. Is this intentional?
The lower bound is based on what we build against. We might try to reduce this later in the release cycle by building and testing against an older version.
