Community
Participate
Working Groups
Unfortunately the steps to reproduce this are long, but they represent what we always do when developing EMF with Eclipse. I'll create some attachments showing the steps described in text below. Start with a fresh environment using RC2 on Windows 2000 with this JRE: java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cndev-20040605 (JIT enabled: jitc)) and use -vmargs -Xj9 when running eclipse.exe Shadow the EMF plugins into the workspace and direct them to also go into the actual plugins directory of the running Eclipse; see the first three images. Once it finishes building, exit Eclipse, run the script to create the jar files that are needed by the plugin.xml files: for i in \ plugins/org.eclipse.emf.codegen/runtime/codegen.jar \ plugins/org.eclipse.emf.codegen.ecore/runtime/codegen.ecore.jar \ plugins/org.eclipse.emf.codegen.ecore.ui/runtime/codegen.ecore.ui.jar \ plugins/org.eclipse.emf.codegen.ui/runtime/codegen.ui.jar \ plugins/org.eclipse.emf.common/runtime/common.jar \ plugins/org.eclipse.emf.common.ui/runtime/common.ui.jar \ plugins/org.eclipse.emf.ecore/runtime/ecore.jar \ plugins/org.eclipse.emf.ecore.change/runtime/ecore.change.jar \ plugins/org.eclipse.emf.ecore.change.edit/runtime/ecore.change.edit.jar \ plugins/org.eclipse.emf.ecore.edit/runtime/ecore.edit.jar \ plugins/org.eclipse.emf.ecore.editor/runtime/ecore.editor.jar \ plugins/org.eclipse.emf.ecore.xmi/runtime/ecore.xmi.jar \ plugins/org.eclipse.emf.edit/runtime/edit.jar \ plugins/org.eclipse.emf.edit.ui/runtime/edit.ui.jar \ plugins/org.eclipse.emf.mapping/runtime/mapping.jar \ plugins/org.eclipse.emf.mapping.ui/runtime/mapping.ui.jar \ plugins/org.eclipse.emf.mapping.ecore2ecore/runtime/mapping.ecore2ecore.jar \ plugins/org.eclipse.emf.mapping.ecore2ecore.editor/runtime/mapping.ecore2ecore.e ditor.jar do ( mkdir -p $(dirname $i) cd $(dirname $(dirname $i))/bin echo zip -r ../runtime/$(basename $i) * zip -r ../runtime/$(basename $i) * ) done Use the library.mdl from the tutorial to generate the library projects: http://download.eclipse.org/tools/emf/scripts/docs.php?doc=tutorials/clibmod/cli bmod.html Shut down Eclipse again and start it up again. You'll either see errors right away, or if you open a .java file from the library project up, you'll see errors as shown in the attachment. If you add a space to the file and save it, you will see errors in the workspace, as shown the the attachment. If you edit the properties and toggle the property shown in the attachment on and then off again (only on is shown), and rebuild, all the problems go away.
Created attachment 12261 [details] Where to find EMF plugins
Created attachment 12262 [details] Which plugins to shadow
Created attachment 12263 [details] Where to check out the projects, i.e., into the real Eclipse plugins directory of the installation
Created attachment 12264 [details] Errors in .java file in the restarted Eclipse
Created attachment 12265 [details] Errors in workspace if the project is rebuilt
Created attachment 12267 [details] Changing build properties with a no-op change and rebuilding fixes the problem
Ed : We suspect that this issue was fixed by PDE earlier this week, do you have time today to check it with last night's integration build?
Wassim - could this be a dup of bug 66766 ?
This is definitely not related to bug 66766. The problem in said bug was very specific to a scenario when dealing with fragments that use an explicit manifest.mf and that use the new format for indicating plugin dependencies, ie. its manifest header would contain the attribute bunde-version:[3.0.0, 4.0.0) for example. This was resulting in an incomplete classpath in the scenario from bug 66766, not because of timing/threading issues, but because PDE was not matching the fragment with its parent. So the classpath would always be incomplete and no amount of rebuilds in the world could make things fine again. In this case, the fact that an explicit rebuild is needed to fix the problem after a no-op change suggests that the classpath was indeed up-to-date, and an explicit rebuild was still needed to get rid of the errors. Note to Ed: In the future, when you attach screenshots of such nature, please expand the "Plug-in Dependencies" node of your plug-in project in the Package Explorer so that we could verify that the classpath is complete. Question for Ed: Does the build.properties file that you touched contain a jars.extra.classpath key in it?
I talked to Ed, he tried on the latest integration build & it worked fine.
