Community
Participate
Working Groups
I tried to view the source for IOConsole (from org.eclipse.ui.console) but Eclipse couldn't find the source. The source plug-in appears in the Source Code Locations tab of the target platforms page so I'm not sure why the source couldn't be found. This is with build I20070418-1012.
I should also add that I tried to add the Source location manually to see if that would help. This resulted in the same entry appearing in the two sections of the tree. I then removed it from the bottom section (i.e. clicked on the second entry and clicked Remove) but this removed the top entry. The addition of duplicate entries should probably be prevented.
I can view the source for IOConsole just fine using that build. Is this an out-of-the-box I-20070418-1012? The only way the source would not be found is if there is a mismatch in version number between the binary org.eclipse.ui.console and its corresponding source plug-in.
The binary and the source plug-in both come from the same build. I've done some playing around and I can see various Equinox/OSGi related source but I can;t see the source from org.eclipse.core.runtime, for instance. Is there any tracing I can turn on to see why that source isn't being found? I have several plug-ins loaded as source, could it be a version mismatch between a plug-in I have in my workspace and the source plug-in that is causing the problem?
>Is there any tracing I can turn on to see why that source isn't being found? No, we don't have tracing available for source attachments. >could it be a version mismatch between a plug-in I >have in my workspace and the source plug-in that is causing the problem? No, because we only use source code location lookup when attaching source to JARs from the target. Side (and unrelated) note: With the recent versioning scheme (ie. the long qualifier in the fourth segment of the version), you are always going to have a mismatch between workspace and source plug-ins, since the workspace version has a '.qualifier' while the source plug-in has the expanded version. Do you have anything stale in your workspace that may be causing this? ie. some binary linked plug-in or the project that houses the 'Add to Java Search' function. There is a problem with this project in the latest build.
I don't have any binary plug-ins as I just get the source from the repository when I want to load a project's source. I did have a Java Search project but I deleted it a few days ago.
If you import org.eclipse.ui.console as binary project into your workspace via the plug-in import wizard, do you find source attached to it?
I couldn't try that project but I tried org.eclipse.core.jobs which had the same problem. The import worked (i.e. the source was included).
why couldn't try that project?
I had already loaded the source from the repository.
I was able to reproduce. This looks like a source attachment issue, not a problem with locating the source. This one is indeed troubling. It happens on some JARs, but not all. The source attachment properties of the JARs look OK on the Java Build Path property page of the project referencing the JAR. Here is a scenario to reproduce: 1. Fresh workspace 2. Create a Hello World plug-in 3. In the Package Explorer, double-click on any class in the org.eclipse.core.runtime.xxx JAE ==> No source 4. Try any class in the org.eclipse.core.jobs.xxx JAR ==> No Source 5. Try any class in org.eclipse.ui.workbench.xxx JAR ==> You will see source If you inspect the source attachment properties of all these JARs in the Java build path properties page, you will see that they are all there. If you import org.eclipse.core.runtime and org.eclipse.core.jobs into your workspace via the plug-in import wizard, you will see source. This proves that source is being correctly located by PDE. Yet for some reason, it is not showing up.
cc Dani as he may know something.
Anything in the .log? Could it be the same old problem with incomplete class path and JDT Core giving up in the middle of getting the attached source?
There was nothing from JDT in the log for me.
(In reply to comment #12) > Could it be the same old problem with incomplete class > path and JDT Core giving up in the middle of getting the attached source? > Dani, what "same old problem" are you referring to ?
The one where we get into trouble when the build path is not complete (bug 73957).
(In reply to comment #15) > The one where we get into trouble when the build path is not complete (bug > 73957). But bug 73957 is about incomplete classpath not about attached source. The attached source is not used during name resolution.
I did not say it IS that issue. Not knowing all the JDT Core I just made a guess.
(In reply to comment #17) > I did not say it IS that issue. Not knowing all the JDT Core I just made a > guess. > I did not say YOU said it is that issue. I just confirmed that it was not that issue after I understood what "old same problem" you were talking about.
(In reply to comment #10) > Here is a scenario to reproduce: > 1. Fresh workspace > 2. Create a Hello World plug-in > 3. In the Package Explorer, double-click on any class in the > org.eclipse.core.runtime.xxx JAE ==> No source > 4. Try any class in the org.eclipse.core.jobs.xxx JAR ==> No Source This works for me. Any more details on how to reproduce ?
I think I found the scenario. You need to: 1. create the workspace with I20070404 2. open a type in core.runtime. 3. shutdown 4. upgrade to I20070418 5. restart the workspace. Then you will see that no source is available for any core.runtime types.
This is a consequence of the fix for bug 145329
Created attachment 64865 [details] Proposed fix and regression test
Note that there is also unrelated bug 183958.
Fix and test released for 3.3M7 in HEAD.
Verified for 3.3 M7 using build I20070427-0010
