Community
Participate
Working Groups
Eclipse F3 0612 Linux Motif Fresh install, brand new workspace. Window -> Preferences -> Java -> ClassPath Variables For ECLIPSE_HOME the value is "Variable Initialization In Progress". Eclipse was installed in /home/torres/Eclipse/ide/motif
The variable is contributed by PDE
This is not an error - ECLIPSE_HOME is programmatically set by PDE but PDE is not loaded on startup. ECLIPSE_HOME variable will be defined by PDE on demand (if not already defined). If a project's classpath contains entries with ECLIPSE_HOME, JDT Core will load PDE Core plug-in to initialize the variable because PDE Core registers variable initializer for it.
How exactly does this get triggered? The reason I found the error was that I had loaded some SWT examples from CVS (see org.eclipse.swt.examples.launcher for example). The .classpath referenced ECLIPSE_HOME and the project didn't compile. When I did the exact same thing on Windows and GTK the ECLIPSE_HOME variable was set for me and everything compiled.
JDT Core declares an extension point for classpath variable initializers. PDE Core register an initializer. When JDT Core tries to compile something and notices that a variable that is on the classpath is not initialized, it loads the initializer to do it. If this didn't happen, it is a JDT Core bug.
The fact it did work on Windows makes me think that some badness occurred while initializing the CP variable registered by PDE. The value which is persisted "Variable Initialization In Progress" should never be visible (need to investigate why) like if the initializer did not complete. The way to figure that the initializer got invoked is to enable the CP variable tracing: # Turn on debug tracing for org.eclipse.jdt.core plugin org.eclipse.jdt.core/debug=true # Reports classpath variable initialization, and classpath container resolution org.eclipse.jdt.core/debug/cpresolution=true For variables, failed initialization are cached, and therefore the initializer should not be called more than once per session.
Found some guilty code persistent this temporary value, which is only visible if the cp initializer did not succeed to bind the variable. Failure should however not be cached. Fix is available for F4 However, PDE should investigate why their initializer did not succeed.
Actually, logged bug 20325 for JDT/Core issue. This one PR belongs to PDE for addressing the initializer failure.
I believe this related so instead of opening a new bug I will append my findings here. Reproducable on F3,GM1 and GM2 The order of operations affect the setting of the ECLIPSE_HOME variable. If I unzip a new eclipse and on startup immediately go to the preferences page. Goto Java->Classpath variables I will see 3 (all JRE_...) no ECLIPSE_HOME Next go to Plug-In development->Target platform and press "Not in workspace" on selecting OK I see a message saying that classpath variables have changed. If I go back to the Java-Classpath page it doesn't have ECLIPSE_HOME set. If I reverse the order and go to the PDE setting first then go to the classpath variables the ECLIPSE_HOME will be set and everything works as expected. I had to manually add ECLIPSE_HOME to make my projects build.
*** Bug 20999 has been marked as a duplicate of this bug. ***
*** Bug 20994 has been marked as a duplicate of this bug. ***
I just fixed our ECLIPSE_HOME initialization problem and released the code in HEAD. So people should no longer run into compilation problems. However, JDT UI needs to look at the problem that Alan points out above: Using a fresh workspace, if the user performs the sequence Window->Preferences- >Plug-in Development->Target Platform, and then go the classpath variables page, he will see all the variables as expected. However, if the user goes to the classpath variables page first, then the Target Platform page, and then back to the classpath variables page, he will only see the three reserved variables!!! So even though, PDE set all the variables correctly when the user selected the Target Platform page (as I verified by a call to JavaCore.getClasspathVariables ()), when he selects the classpath variables page for the second time, that page does NOT refresh its contents by a new call to JavaCore.getClasspathVariables(). Even worse, the class VariableBlock will remove all PDE classpath variables from the VM upon pressing OK, because they are not explicitly in its list.
Philippe, question: If the variable is not created yet, will jdt.core create it if it finds it in the contribution? I think it should. (It shouldn't initialize it, but simply declare it (with null value)). So when the jdt.ui preference page comes up, JavaCore.getClasspathVariableNames includes this name and will be correctly initalized.
Currently it does not, but I agree it should infer variable names by looking at all registered initializers... Don't we have the same issue for containers ?
Fixed JavaModelManager.loadVariables() to also include variables for which there are extensions points defined. This fixes the scenario Alan described: when going to the Classpath Variables preferences, the ECLIPSE_HOME variable is listed and initialized by PDE.
*** Bug 24600 has been marked as a duplicate of this bug. ***
Verified.
