Community
Participate
Working Groups
I exported my preferences on a pc. I imported my preferences on a mac. When I go to the user libraries pane (or attempt to open a project referencing one of the imported libraries) there is an error "Path for IClasspathEntry must be absolute" (see traceback from pde error log below). I can see from the workspace file .plugins/org.eclipse.jdt.core/variablesAndContainers.dat that some of the user libraries have been imported from the pc and that their path is non absolute in mac terms. however as that file is an opaque binary format and I can't open the user libraries pane, my workspace is basically corrupted now... Traceback: --------------------- org.eclipse.core.runtime.AssertionFailedException: assertion failed: Path for IClasspathEntry must be absolute at org.eclipse.core.runtime.Assert.isTrue(Assert.java:109) at org.eclipse.jdt.core.JavaCore.newLibraryEntry(JavaCore.java:3829) at org.eclipse.jdt.internal.core.UserLibrary.createFromString(UserLibrary.java:188) at org.eclipse.jdt.internal.core.UserLibraryManager.recreatePersistedUserLibraryEntry(UserLibraryManager.java:169) at org.eclipse.jdt.internal.core.UserLibraryManager.getLibraryMap(UserLibraryManager.java:145) at org.eclipse.jdt.internal.core.UserLibraryManager.getUserLibrary(UserLibraryManager.java:84) at org.eclipse.jdt.internal.core.UserLibraryClasspathContainerInitializer.initialize(UserLibraryClasspathContainerInitializer.java:32) at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:2203) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1545) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1571) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2558) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1848) at org.eclipse.jdt.internal.core.JavaModelManager.determineIfOnClasspath(JavaModelManager.java:904) at org.eclipse.jdt.internal.core.JavaModelManager.create(JavaModelManager.java:790) at org.eclipse.jdt.internal.core.JavaModelManager.create(JavaModelManager.java:730) at org.eclipse.jdt.core.JavaCore.create(JavaCore.java:1456) at org.eclipse.jdt.internal.ui.ResourceAdapterFactory.getAdapter(ResourceAdapterFactory.java:44) at org.eclipse.core.internal.runtime.AdapterFactoryProxy.getAdapter(AdapterFactoryProxy.java:61) at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:277) at org.eclipse.core.runtime.PlatformObject.getAdapter(PlatformObject.java:66) at org.eclipse.mylyn.internal.java.ui.JavaStructureBridge.acceptsObject(JavaStructureBridge.java:211) at org.eclipse.mylyn.context.core.ContextCorePlugin.getStructureBridge(ContextCorePlugin.java:208) at org.eclipse.mylyn.internal.context.ui.InterestDecoratorLightweight.decorate(InterestDecoratorLightweight.java:36) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:259) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:71) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:857) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:336) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:322) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:369) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:329) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Update to this: it appears the problem is to do with a classplath variable being in windows format, being used as the "source path" for an existing library. deleting the classpath variable doesn't make the problem go away
It looks like a dup of bug 202373. Moving to JDT/UI
After all, it might not be a dup (the stack traces are different). Moving back to JDT/Core to investigate.
Tim, I will need some information to track this issue: 1. What is the Eclipse build number you are using ? 2. Was the exported preferences ever edited ? 3. Can you please attach the exported preferences to this bug ? 4. Can you please clarify comment 1 ? How did you make such diagnosis ?
Created attachment 79212 [details] the prefs file I imported
> Tim, I will need some information to track this issue: > 1. What is the Eclipse build number you are using ? The (osx-based) eclipse I am importing into gives the following: Version: 3.3.0 Build id: I20070621-1340 > 2. Was the exported preferences ever edited ? No. (hence don't see this is a duplicate of bug 202373 > 3. Can you please attach the exported preferences to this bug ? attached > 4. Can you please clarify comment 1 ? How did you make such diagnosis ? I think I was a bit too hasty in that comment - it's more of a hunch than a diagnosis, knowing my workspace. ---- more on that hunch (of limited use?) The hunch is that it is about source attachments. But I did found errors in the error log that referred to particular classpath variables. I have removed those classpath variables and had a different problem (I think an NPE, but not sure - could check if this is likely to be useful). I then put those variables back in but with a valid osx path - and got the IclasspathEntry must be absolute assertion error again. As for the reasons behind my hunch, I'm aware from experience that if you have non-extant source attachments (or, I think, javadoc) for a jar (not just a userlibary) this has caused console-traceback clicks (into a _different_ library - not the jar with the problematic source attachment) to fail with a slightly obscured error (never reported this I'm afraid). As I say - just a hunch - I may well be wrong. ---- As a further note - reexporting preferences under mac osx and then reimporting into a new workspace did not recapture the bug (I could enclose the reexported prefs if that was the case)
actually I was wrong about exporting and importing. exporting the preferences and reimporting on a clean workspace DID cause the problem to go away. However, by removing the following line from two offending projects, I removed the error warning from startup: <classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/tools.jar"/> I then still got the IClasspathEntry must be absolute assertion error when trying to open the User Libraries preference pane. This implies to me that there is a problem with the tools.jar user library (and maybe others). I have then (as a test) manually edited the preferences file to replace all windows path attributes in the file (regexp "(c|d)\\:[^"]*" ) with a valid but spurious osx path /Users/tim/nonexistant.jar). I then imported this file and, hey presto - I could view the User Libraries preference pane again. I can post this file if that would help. So I'm very confident this is a problem with importing preferences which contain windows paths on a macintosh machine. Some possibilites I'd guess, is to do checking on each path as it comes in, and either abort/undo the preference import process or subsitute a valid but spurious path, or maybe (if possible) just check what platform the preferences were exported on, and if no match refuse to continue.
Looking at the exported preferences from comment 5, I see that invalid entries are being exported. E.g. /instance/org.eclipse.jdt.core/org.eclipse.jdt.core.userLibrary.Catalina\ libraries=\#\#<cp entry ignore>\#\# This is fixed in the R3_3_maintenance stream. Could you please try the latest maintenance build (e.g. http://download.eclipse.org/eclipse/downloads/drops/M20070921-1145/index.php), export your preferences with this build on your pc, then import them with this same build on your mac ? And let me know if this fixes this problem ?
Closing since no update since 2007/09/27
Verified for 3.5M2 using I20080914-2000.
