Summary: | Importing windows prefs on a mac can cause some preferences panes to become unopenable | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Tim Diggins <tim> | ||||
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||
Status: | VERIFIED WORKSFORME | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | jerome_lanneluc, tim | ||||
Version: | 3.3 | ||||||
Target Milestone: | 3.5 M2 | ||||||
Hardware: | Macintosh | ||||||
OS: | Mac OS X - Carbon (unsup.) | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Tim Diggins
2007-09-25 12:01:11 EDT
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. |