Community
Participate
Working Groups
I understand that in Eclipse 3.0 the prefix path for source jars attachments (the "root path" field in Attach Source dialog for previous versions)is now automatically "inferred". This does not seem to work for jars contributed by one of our vendors who uses the following pattern when packaging : - .class files and .java files are located in the same jar - .class files are located under xxx/yyy, where "xxx.yyy" is the correct package name - .java files are located under corejrisk/src/xxx/yyy Now in my beloved 2.0.1 version of Eclipse I simply set "root path" to "corejrisk/src" when attaching the source jar and it works perfectly. I also understand that the "rootpath" attribute in the matching .classpath entry was supported in more recent versions even after the "root path" field had disappeared from the Attach Source dialog. But in the 3.0 version the "rootpath" attribute no longer seems to work, while the "inference" mechanism apparently fails to pick up the appropriate source file. People around me have resorted to unzipping the source files to folders, but this is a pain as we incorporate new jars of that type on a regular basis. I perused the Newsgroup on dev.eclipse.org and found an entry for this problem, dated Sep. 15 2003, where the conclusion was : "The prefix path should be automatically detected now. If it is not in your case, please enter a bug against JDT/Core with steps to reproduce the problem." The exact Eclipse version I am referring to is 3.0.0, build 200406251208.
From your decription, I created a Java project with the attached jar on its build path. I attached the same jar as its own source attachment and I was able to see the source of X.class. Did I miss something ?
Created attachment 14606 [details] The jar to put on the build path
Created attachment 14659 [details] reproduces the "source not found" symptom Took a harder look at the vendor jar and it seems that what gets Eclipse confused is the presence of another .class file for the same object but with a different path. This other path starts with the same folder name as the source file path, and that seems to have a bearing on the problem (see the other attachement).
Created attachment 14660 [details] jar that does not reproduce the "source not found" problem Now this jar is very similar to the "repro.jar" one except that the "parasite" .class object has a completely unrelated path (no common prefix with source file path). In this configuration Eclipse has no problem retrieving the source file.
Ran a couple of other tests on path for 'parasite' .class object : - tried "anotherpath/corejrisk/lib/xxx/yyy" : works fine - tried "lib/xxx/yyy" : also OK From here it looks like it's the initial folder identity that creates the confusion. Unfortunately for us this is just the way all those jars are packaged. I tried all these test jars in my 2.0.1 Eclipse and, with the correct setting for the "root path" field, have no problem accessing the source code. So to me it does feel like a regression.
Thanks for taking the time to give a good test case. I was able to reproduce the problem with the attached jar. Problem is that SourceMapper#computeAllRootPaths(...) stops at the first 'first level package name'. If a .class file is included in several root paths, only the first root path will be considered. Fixed SourceMapper#computeAllRootPaths(...) to consider the whole path of an entry (also changed it to skip non-java entries). Added regression test AttachSourceTests#testRootPath12() Released in both HEAD and R3_0_maintenance branches.
Verified for 3.1 M2 with build I200409230800.
Candidating for 3.0.2
Note this is not committed yet
