Community
Participate
Working Groups
In 2.1 M4 the source attachment no longer shows the field root path. For this reason, source attachment will not work. I had projects created with older version of Eclipse and those are functioning alright. I was reading in bug: 27018, that the UI field for rootpath is no longer necessary. With my source jar files it is still necessary. I edited the .classpath file manually to add the rootpath field, and after restarting Eclipse, I can see corectly the attachment. My source jar files have the rootpath src/java.
Moving to core since they now probe the root path of a source attachement.
Please provide an example of such a jar file. Attach it to this message and give steps to reproduce.
I am not able to reproduce it any more. What I found that if rootpath="" is present in the .classpath file, the source can not be seen. But if I reattach, the rootpath="" disappear from the .classpath file and everything is OK. I think you can close this bug.
Do you have any idea how the rootpath was equal to ""? I think this is a bug. Did you reuse an old workspace? Could you reproduce it from scratch?
We only infer the rootpath if none was specified. This sounds like an update issue, where moving from an old workspace where UI did set it to "" (when reattaching sources, it did not set the rootpath anymore, resulting in the .classpath file not containing it any longer). Either we should treat "" as if absent (sounds bad), or UI should still allow users to set a custom one - we even have an API to infer it). Removing the rootpath button is wrong I believe, it should still be there in order to deal with advanced scenarii (where multiple rootpaths would be available for instance). Back to JDT/UI to reconsider the rootpath button removal.
We can't bring the UI back. That we could remove the UI for the root path was a big usability improvement; the explanation of the field was half a dialog of text. Having it in again would double the confusion. My suggestion is that CORE ignores any existing root paths and relies on the automatically detected rootpaths. As before we rely on a certain format of the JAR file structure. Multiple rootpaths ask for trouble. In such a case, I think its ok to ask the user to reorganize the JAR, with the new or unzip it to a folder. If the multiple root case is really becoming a problem (and many users complaning about it), the automated solution could for example even look inside class/ and CU to detect the best match. Moving back to JCore
We cannot ignore the rootpath setting, this would be loosing some information. It reflects the information passed along on the classpath. As for asking JAR reorganization, this can only be done in UI land. Advanced scenarii will require to specify a rootpath to avoid ambiguities, this means it would need a UI for it. I could understand that you don't want to address it now, but this belongs to UI anyway.
The cases where a specification of a root really is important (because the source JAR has a problematic content) are rare to none existing. The chance that a user configures the root wrong are bigger than the gain of being able to specify it.
Fair enough, will close with no further action then.
For avoiding problems with old workspaces, existing root path settings should be ignored if no source can't be found under it.
This isn't an easy thing to do. Sources can be sparse... but this is a good suggestion.
Could we use the rootpath as a hint only ?
Changed SourceMapper to recompute the root path if the source is not found. Added regression test AttachSourceTests.testRootPath2() and testRootPath3()
Verified.
