Community
Participate
Working Groups
Eclipse 2.1 RC1 Every time I restart Eclipse it seems that some projects have their build path broken. Even though the correct JARs are on the classpath if I try code assist or reorganize imports, things do not work. For code assist it does not find any completions and organize imports removes valid import statements from the file. If I rebuild all, everything goes back to normal but if I exit and restart Eclipse things are broken again. Have you experienced anything similar before? What could be wrong? I can provide the workspace upon request.
Olivier - please investigate with Rodrigo
This was an issue with the editor and the positions inside the editor. Seems to be fixed using latest 0227 integration build. Closed as WORKSFORME.
It happened again this morning with I20030227.
This problem is due to the resolution of classpath variables when the workspace starts. Rodrigo uses a lot of variables in his project's classpath like: ECLIPSE_HOME/...../jdtcore.jar .... When the workspace starts, no type in jdtcore.jar can be found. A search to references of IJavaElement returned no matches. Editing the project's properties>Java build path and simply click OK without changing anything fixes the problem. These variables in the java browsing perspective are not shown till the build path is recomputed. I am trying to isolate a simple test case without much success so far.
Its project .classpath looks like this: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src/"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.core.resources_2.1.0/resources.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.core.resources_2.1.0/resourcessrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.ui_2.1.0/ui.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.ui_2.1.0/uisrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.swt.win32_2.1.0/ws/win32/swt.jar" sourcepath="ORG_ECLIPSE_PLATFORM_WIN32_SOURCE_SRC/org.eclipse.swt.win32_2.1.0/ws/win32/swtsrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.text_2.1.0/text.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.text_2.1.0/textsrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.jface_2.1.0/jface.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.jface_2.1.0/jfacesrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.jface.text_2.1.0/jfacetext.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.jface.text_2.1.0/jfacetextsrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.ui.views_2.1.0/views.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.ui.views_2.1.0/viewssrc.zip"/> <classpathentry kind="src" path="/org.eclipse.ui.workbench"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.ui.workbench.texteditor_2.1.0/texteditor.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.ui.workbench.texteditor_2.1.0/texteditorsrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.ui.editors_2.1.0/editors.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.ui.editors_2.1.0/editorssrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.jdt.core_2.1.0/jdtcore.jar" sourcepath="ORG_ECLIPSE_JDT_SOURCE_SRC/org.eclipse.jdt.core_2.1.0/jdtcoresrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.jdt.ui_2.1.0/jdt.jar" sourcepath="ORG_ECLIPSE_JDT_SOURCE_SRC/org.eclipse.jdt.ui_2.1.0/jdtsrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.core.boot_2.1.0/boot.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.core.boot_2.1.0/bootsrc.zip"/> <classpathentry kind="var" path="ECLIPSE_HOME/plugins/org.eclipse.core.runtime_2.1.0/runtime.jar" sourcepath="ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.core.runtime_2.1.0/runtimesrc.zip"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath> I tried to reproduce it, but the classpath gets resolved properly all the time. So I don't know what is specific to Rodrigo's workspace to have its classpath variable not initialized on startup.
If PDE's variable initializer didn't do its job, then it would definitely cause the trouble Rodrigo is seeing. Cc'ing Dejan for comment on this. Also, Olivier/Rodrigo, can you enable the JDT/Core debug traces to see what's going on during startup ? org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/cpresolution=true
We have a variable initializer registered, and it should be used by JDT Core.
I will try in debug mode and let you know what I get.
The problem is related to the classpath variable initialization in conjunction with the usage of links files. If Rodrigo doesn't use any links file anymore, the problem disappear. I will provide the debug trace as soon as the mail system is back in order.
Here is the first part of the trace: CPContainer INIT - reentering access to project container: [org.eclipse.ui.examples.tileeditor] org.eclipse.jdt.launching.JRE_CONTAINER during its initialization, will see previous value: Persisted co ntainer [org.eclipse.jdt.launching.JRE_CONTAINER for project [org.eclipse.ui.examples.tileeditor] CPContainer INIT - after resolution: [org.eclipse.ui.examples.tileeditor] org.eclipse.jdt.launching.JRE_CONTAINER --> container: JRE System Library [ibmjdk131] {D:/IBMJDK131/jre/lib/rt.jar[CPE_LIBRARY ][K_BINARY][sourcePath:d:/ibmjdk131/src.jar][rootPath:src][isExported:false] , D:/IBMJDK131/jre/lib/i18n.jar[CPE_LIBRARY][K_BINARY][sourcePath:d:/ibmjdk131/src.jar][rootPath:src][isExported:false] , D:/IBMJDK131/jre/lib/ext/ibmjcaprovider.jar[CPE_LIBRARY][K_BINARY][sourcePath:][rootPath:][isExported:false] , D:/IBMJDK131/jre/lib/ext/indicim.jar[CPE_LIBRARY][K_BINARY][sourcePath:][rootPath:][isExported:false] , D:/IBMJDK131/jre/lib/ext/JawBridge.jar[CPE_LIBRARY][K_BINARY][sourcePath:][rootPath:][isExported:false] } CPVariable INIT - no initializer found for: ECLIPSE_HOME_ORG_ECLIPSE_GEF_LINK CPVariable INIT - no initializer found for: ECLIPSE_HOME_ORG_ECLIPSE_GEF_LINK CPVariable INIT - reentering access to variable: ECLIPSE_HOME during its initialization, will see previous value: D:/eclipse/runtimes/I20030227/eclipse CPVariable INIT - no initializer found for: ECLIPSE_HOME_ORG_ECLIPSE_GEF_LINK CPVariable INIT - no initializer found for: ECLIPSE_HOME_ORG_ECLIPSE_GEF_LINK CPVariable INIT - no initializer found for: ECLIPSE_HOME_ORG_ECLIPSE_GEF_LINK CPVariable INIT - after initialization: ECLIPSE_HOME --> D:/eclipse/runtimes/I20030227/eclipse
Then we also got these exceptions (quite a lot). They are not in the .log file: java.lang.Exception: FAKE exception for dumping current CPContainer ([org.eclipse.ui.examples.tileeditor] org.eclipse.jdt.launching.JRE_CONTAINER)INIT invocation stack trace at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:885) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1532) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1469) at org.eclipse.jdt.internal.core.JavaProject.computeExpandedClasspath(JavaProject.java:238) at org.eclipse.jdt.internal.core.JavaProject.getExpandedClasspath(JavaProject.java:1066) at org.eclipse.jdt.internal.core.JavaProject.getExpandedClasspath(JavaProject.java:1053) at org.eclipse.jdt.internal.core.SetClasspathOperation.updateAffectedProjects(SetClasspathOperation.java:606) at org.eclipse.jdt.internal.core.SetClasspathOperation.generateClasspathChangeDeltas(SetClasspathOperation.java:472) at org.eclipse.jdt.internal.core.SetClasspathOperation.updateClasspath(SetClasspathOperation.java:575) at org.eclipse.jdt.internal.core.SetClasspathOperation.executeOperation(SetClasspathOperation.java:243) at org.eclipse.jdt.internal.core.JavaModelOperation.execute(JavaModelOperation.java:365) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:681) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1588) at org.eclipse.jdt.internal.core.JavaElement.runOperation(JavaElement.java:544) at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:2172) at org.eclipse.jdt.core.JavaCore$4.run(JavaCore.java:3146) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:34) at org.eclipse.jdt.internal.core.JavaModelOperation.execute(JavaModelOperation.java:365) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:681) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1588) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:2699) at org.eclipse.jdt.core.JavaCore.updateVariableValues(JavaCore.java:3134) at org.eclipse.jdt.core.JavaCore.removeClasspathVariable(JavaCore.java:2651) at org.eclipse.pde.internal.core.EclipseHomeInitializer.resetEclipseHomeVariables(EclipseHomeInitializer.java:43) at org.eclipse.pde.internal.core.EclipseHomeInitializer.initialize(EclipseHomeInitializer.java:35) at org.eclipse.jdt.core.JavaCore$2.run(JavaCore.java:1016) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:867) at org.eclipse.core.runtime.Platform.run(Platform.java:413) at org.eclipse.jdt.core.JavaCore.getClasspathVariable(JavaCore.java:1011) at org.eclipse.jdt.core.JavaCore.getResolvedVariablePath(JavaCore.java:1754) at org.eclipse.jdt.core.JavaCore.getResolvedClasspathEntry(JavaCore.java:1671) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1522) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1469) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1445) at org.eclipse.jdt.internal.core.DeltaProcessor.initializeRoots(DeltaProcessor.java:1099) at org.eclipse.jdt.internal.core.JavaModelOperation.execute(JavaModelOperation.java:362) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:681) at org.eclipse.jdt.internal.core.JavaElement.runOperation(JavaElement.java:541) at org.eclipse.jdt.internal.core.CompilationUnit.getSharedWorkingCopy(CompilationUnit.java:582) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.createElementInfo(CompilationUnitDocumentProvider.java:852) at org.eclipse.ui.texteditor.AbstractDocumentProvider.connect(AbstractDocumentProvider.java:302) at org.eclipse.ui.texteditor.AbstractTextEditor.doSetInput(AbstractTextEditor.java:2287) at org.eclipse.ui.texteditor.StatusTextEditor.doSetInput(StatusTextEditor.java:160) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.doSetInput(JavaEditor.java:1558) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSetInput(CompilationUnitEditor.java:909) at org.eclipse.ui.texteditor.AbstractTextEditor$8.run(AbstractTextEditor.java:1788) at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:296) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:246) at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:431) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:65) at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:428) at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:1362) at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(AbstractTextEditor.java:1803) at org.eclipse.ui.texteditor.AbstractTextEditor.init(AbstractTextEditor.java:1820) at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:598) at org.eclipse.ui.internal.EditorManager.openInternalEditor(EditorManager.java:660) at org.eclipse.ui.internal.EditorManager.access$7(EditorManager.java:649) at org.eclipse.ui.internal.EditorManager$7.run(EditorManager.java:913) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:867) at org.eclipse.core.runtime.Platform.run(Platform.java:413) at org.eclipse.ui.internal.EditorManager.busyRestoreEditor(EditorManager.java:858) at org.eclipse.ui.internal.EditorManager$6.run(EditorManager.java:851) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:65) at org.eclipse.ui.internal.EditorManager.restoreEditor(EditorManager.java:847) at org.eclipse.ui.internal.EditorManager.restoreState(EditorManager.java:750) at org.eclipse.ui.internal.WorkbenchPage.restoreState(WorkbenchPage.java:2232) at org.eclipse.ui.internal.WorkbenchWindow.restoreState(WorkbenchWindow.java:1302) at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:1132) at org.eclipse.ui.internal.Workbench.access$9(Workbench.java:1092) at org.eclipse.ui.internal.Workbench$10.run(Workbench.java:1010) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:867) at org.eclipse.core.runtime.Platform.run(Platform.java:413) at org.eclipse.ui.internal.Workbench.openPreviousWorkbenchState(Workbench.java:962) at org.eclipse.ui.internal.Workbench.init(Workbench.java:742) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1242) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539)
Wassim, take a look at the comment 10 from Olivier. It looks like classpath intializer cannot be found for the variables created from link files in the target platform. How do we initialize these (can we at all)?
Rodrigo is using two links files. One for GEF and another one for another project. This prevents him from loading lot of plugins in his workspace.
PDE has a classpath variable initializer registered for ECLIPSE_HOME. In the presence of links however (as in Rodrigo's case), PDE also reads the contents of the link files and assigns an ECLIPSE_HOME_* variable to account for the additional plug-in locations. Due to the dynamic nature of these link variables, we cannot register classpath variable initializers for them, so what we do is piggy-back on the original ECLIPSE_HOME initializer. When that initializer is called, PDE computes the new value of ECLIPSE_HOME, then removes all the link ECLIPSE_HOME_* variables (if any) and computes the new ones (if any) from the link files. Removal and recomputation is necessary as these links could vary in number and location from one startup to the next. This seems to be causing a problem for JDT Core's resolution of the classpath. Do you have a suggestion for a better approach to address this issue?
Variable initializers do not support dynamic variable name resolution. The resolved variable must be statically registered. Containers would however allow you to address this issue. A container path is formed of a first container ID segment, and then a few hint segments. The container ID identifies a container initializer (i.e. it is the only static portion of the piece to resolve which must have a statically registered initializer), the rest of the container path is dynamically resolved by the initializer. Olivier - the exception traces are fake exception used to trace who's triggering initializer activations.
Moving to PDE/UI, leaving milestone set to drag attention.
Philippe, what we have here are variables for external JARs that we use to avoid having absolute paths in the shared repository. In contrast, classpath containers require that you provide the 'real' classpath entires instead (we use them elsewhere in PDE, so we are familiar). Can you explain in more detail how can classpath containers help us in this situation?
Classpath containers are the way to go in general, and are much more powerful than classpath variables. They allow a few more things: - same container can denote a set of JARs (or projects), where a classpath variable was allowing you to point at one JAR exactly. - containers have a readable description, - container paths is a combination of a static ID and a trailing portion treated as an hint. This being said, I don't know if you still need to use 3 container references to denote 3 JARs, or have them all grouped in one macro entity. But if you want to keep the same granularity, here is how to do it: e.g. instead of using a variable entry: ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.core.resources_2.1.0/resourcessrc.zi p you would use a container entry with path: ECLIPSE_HOME/ORG_ECLIPSE_PLATFORM_SOURCE_SRC/org.eclipse.core.resources_2.1.0/re sourcessrc.zip with your container initializer registered for ID 'ECLIPSE_HOME'. When invoked for all container paths prefixed with 'ECLIPSE_HOME', it would get the entire path, and transform is into whatever it wants. I suspect that it would simply substitue ORG_ECLIPSE_PLATFORM_SOURCE_SRC with the appropriate path, and append the trailing path portion to it: d:/eclipse/src/org.eclipse.core.resources_2.1.0/resourcessrc.zip This way you can have as many references as you need, and only one registered initializer, which can dynamically decide how to resolve them. Note that the container entry doesn't need to have some actual path information into it (I mean for the trailing container hint portion), it is up to you to specify the hint portion in a way which your initializer can decode and expand into actual classpath entries. For instance the JRE initializer is using some generic container ID (let say "JRE", and hints to denote JDK flavors "1.2.2", "1.3", or whatever matches the installed JREs information). Am I making any sense ?
Rodrigo, before I start making major changes this late in the 2.1 cycle, I would like to be able to reproduce the problem. Could you please give me steps to reproduce it?
I haven't tried this in an workspace other than my own so here is a description of my workspace: Eclipse is installed at: D:\eclipse\runtimes\I20030227 GEF is installed at: D:\GEF\I20030220 I have a link file at: D:\eclipse\runtimes\I20030227\eclipse\links\org.eclipse.gef.link with the contents: path=D:/GEF/I20030220 I have an empty file at: D:\GEF\I20030220\eclipse\.eclipseextension In Eclipse, go to File->Import->External Plug-ins and Fragments. Check the "Extract source archieves...", choose org.eclipse.gef and org.eclipse.ui.workbench. In Eclipse, go to Window->Preferences->Plug-in Development->Target Platform and choose "this application" click "reload" and "not in workspace". OK. The GEF plug-in will be broken (no source folder defined) so you have to go to the project properties and choose the existing src-gef as the source folder. There might be still an error on GEF related to references to an internal constant from the Eclipse UI (just disconsider that). My workspace has a few plug-in projects and most of them rely on various Eclipse plug-ins (UI, JDT, ...). The classpath is calculated using the "Update classpath" menu which makes them relative to ECLIPSE_HOME. There is only one plug-in that requires GEF and the classpath is also calculated using the "Update classpath" menu. Hope this is enough for you to reproduce the problem. Let me know how it goes.
thanks Rodrigo, I'll give it a try. One more thing: where do I get gef from?
http://download.eclipse.org/tools/gef/downloads/ I am using version I20030220 but maybe a newer version has fixed those errors I've mentioned above.
I'm going to re-assign it back to JDT Core for the following reason: When you shut down and restart Eclipse on a workspace such as Rodrigo's, go directly to the classpath variables preference page, you will see that ECLIPSE_HOME and ECLIPSE_HOME_COM_ECLIPSE_GEF_LINK are correctly initialized. This is all PDE is required to do and it is doing it. The .classpath files for all projects in the workspace are all accurate and refer to external JARS using the correctly initialized variables. But for some reason, JDT Core needs a rebuild of the projects to recognize the external jars.
As you can see on Olivier's stack traces, there are times where variables are not initializable, and eventually they will get some value. We may have an update issue, since assigning a variable value should refresh all associated markers (providing it occurs in a context where the resource tree isn't locked - is it true?). However the basic issue is that you have no initializer registered for some of your variables, which isn't an expected situation.
Olivier, can you replay the trace and see why when/if offending variable is assigned in the end, it doesn't update the affected projects (debug from JavaCore.setClasspathVariable). Unclear we are going to change this situation that late in the game, as I said earlier, the lazy variable initialization may simply invoked in a context where we are denied the right to create markers (i.e. next build action should clear the unnecessary ones). If this is the case, no action is to be taken for 2.1. This is still a PDE bug, exposing a JDT bug (maybe).
I am not sure I saw anything about the resolution of this variable. I will do it again on Rodrigo's machine and update the PR.
Created attachment 3828 [details] Debug trace This is what I got in debug mode. The problem looks like a refresh problem, because there is nothing in the trace when I edit the build path and then OK. After this works. A rebuild is not necessary. Editing the java build path is enough.
Wassim - from Olivier's trace, it does not seem you are ever setting the value for ECLIPSE_HOME_COM_ECLIPSE_GEF_LINK, since it is requested in vain until the end of the trace. Need to add more info to the trace to see more details. Olivier - could you post Rodrigo's workspace on snz1f ?
Created attachment 3837 [details] EclipseHomeInitializer
In the initializer registered for ECLIPSE_HOME, I initialize ECLIPSE_HOME, and loop through all the links and create a variable for each link. Note that prior to initializing ECLIPSE_HOME, I delete all ECLIPSE_HOME_* variables corresponding to links (so that we don't end up with stale variables corresponding to links from previous configurations that no longer exist in the current configuration). Then after initializing ECLIPSE_HOME, I go through all the links and create a variable for each link. Do you think the removal of the ECLIPSE_HOME_ORG_ECLIPSE_GEF_LINK variable then its recreation is confusing JDT Core? Attached is the initializer class for ECLIPSE_HOME in which all the initializing/removal/recreation is taking place. Please take a look at it.
Note: the PDE initialization code should perform all these operations inside a JavaCore.run batch operation, so as to avoid unnecessary intermediate updates/notifications.
*** Bug 33695 has been marked as a duplicate of this bug. ***
When reentering JavaCore.updateVariableValues(...), now set the oldPath to null so that projects using this variables are updated as well (and the incomplete resolved classpath is removed from the cache). Similar change was made to JavaCore.setClasspathContainer(...)
At my end, I will put all the initialization operations in a JavaCore.run batch operation, as suggested by Philippe.
*** Bug 33918 has been marked as a duplicate of this bug. ***
There is still a problem in RC2. After you restart your workspace, you will see an error in the tasks view: "Unbound classpath variable: 'ECLIPSE_HOME_ORG_ECLIPSE_GEF_LINK/org.eclipse.draw2d_2.1.0/runtime/dr aw2d.jar' If you then open the .classpath file, add a space or something and resave. Everything is fine. I suggest re-opening this bug for further investigation.
We haven't been able to reproduce extra error when testing, all was fine in the end.
Your new problem is bug 34286. This bug can be marked as verified. Verified by Rodrigo.
I've got the message Wassim reports on comment 36 when I've updated my link file to point to a newer version of GEF. Doing "Update classpath" solved that.
