Community
Participate
Working Groups
Build Identifier: M20110119-0834 The source attachment feature does not work properly, when importing Projects with source attachments into an empty workspace. After importing a project with source attachments, the referenced JARs display the correct source attachment path but the internal project ".org.eclipse.jdt.core.external.folders" does not contain the external folder. On previous Helios builds this resulted in an NPE during "Refreshing external folders" (see #321358) The latest build shows no indication of any problems, the source-attachment just does not work. After manually editing the path using the project preferences and clicking "OK" the source attachment displays correctly. After that the source attachment is available in *all* projects that use the external JAR. (And the link is added to the external folders project.) Reproducible: Always Steps to Reproduce: 1. Create a two new projects. 2. Add the same external JAR with source attachment to both projects. 3. Close Eclipse, remove workspace, create a new workspace. 4. Import both projects. - Source attachments are not accessible when navigating the external JAR file - 5. Open the properties of the external JAR in any of both projects. - Source attachment path is displayed correctly and seems reasonable - 6. Use the file dialog to select the same directory again. 7. Click "OK" - Source attachments magically work in *both* projects
After having a look at the source code I could suggest a hack: In .. org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/ClasspathEntry.java Use the ExternalFoldersManager singleton to add sourceAttachments if neccessary. (Maybe already in the ClasspathEntry constructor?) I think this step happens somewhere in the UI part but is not executed when the classpath entry is decoded from XML.
Created attachment 188142 [details] Proposed patch A better solution would be to add the external folders used as source attachments while resolving project classpaths. Would you be able to confirm if the fix works for you?
Thanks for the fast reply! I will try this fix first thing tomorrow. Give me some time though, I have zero experience building Eclipse. :)
Works like a charm! :D Will this fix find it's way into Helios SR2?
(In reply to comment #4) > Works like a charm! :D > > Will this fix find it's way into Helios SR2? I don't have a test yet for this and don't expect to be able to add one soon enough. Olivier, what do you say?
All existing tests pass, though.
(In reply to comment #5) > Olivier, what do you say? Jay, please check if this is a regression over 3.6 or 3.5.2 and report back. If not, then it is too late for 3.6.2.
(In reply to comment #7) > (In reply to comment #5) > > Olivier, what do you say? > Jay, please check if this is a regression over 3.6 or 3.5.2 and report back. > If not, then it is too late for 3.6.2. This must have always been there. The removal of the null-check as part of fix to 313153 exposed the bug in the form of bug 321358 and it's duplicates. But with the NPE symptom, we never got around to find the cause of that NPE, until this bug was reported. So, in a nutshell, this is not a regression.
(In reply to comment #8) > This must have always been there. The removal of the null-check as part of fix > to 313153 exposed the bug in the form of bug 321358 and it's duplicates. But > with the NPE symptom, we never got around to find the cause of that NPE, until > this bug was reported. So, in a nutshell, this is not a regression. Then this should be fixed for Indigo only considering that we are already in RC3 for 3.6.2.
Besides we have a workaround as mentioned in comment #0 (step 5,6 and 7)
(In reply to comment #9) > Then this should be fixed for Indigo only considering that we are already in > RC3 for 3.6.2. Okay, it's not that far away and I have a working patch. Thanks to both of you for your fast support!
Created attachment 188419 [details] Patch with test Same patch with tests added in org.eclipse.jdt.core.tests.model.AttachSourceTests#testBug336046()
Ayush, can you review this please?
Created attachment 188591 [details] Test projects These tests are required to be able to run the regression tests and to be extracted here: \org.eclipse.jdt.core.tests.model\workspace\AttachSourceTests\
Ayush is not able to reproduce this bug and surprisingly neither can I! I know something must have changed in the test environment. But I can't figure out what. These are the steps I have tried several times. 1. Create a new workspace (workspace1), create two new projects, add the same external JAR to both projects. 2. Set the same external folder as source attachment for both folders. 3. Now close workspace1. 4. Delete the workspace1\.metadata folder just to be sure. 5. Create a new workspace, workspace2. 6. Turn off auto build (I don't think this step has any impact now and I didn't have to bother about this earlier when I was able to reproduce) 7. Menu -> import... -> Existing projects into Workspace 8. Select root directory (workspace1) 9. Select the check box "Copy projects into workspace" (I don' think I had to do this earlier too) 10. After getting the projects imported, navigate and expand the external library and try to open any of the class files. This always fetches the source. Jonas, do you find anything amiss here?
(In reply to comment #15) > Jonas, do you find anything amiss here? I'm not exactly sure if it does matter: We usually keep our projects (physically) outside the Eclipse workspace. So we usually never "Copy projects into workspace". That way the workspace folder only contains meta data. We delete the whole folder, when starting from scratch. Also, did you restart Eclipse between your test-runs? The ExternalFoldersManager seems to be a singleton so it probably cached the external directory entries.
(In reply to comment #16) > (In reply to comment #15) > > Jonas, do you find anything amiss here? > > I'm not exactly sure if it does matter: We usually keep our projects > (physically) outside the Eclipse workspace. So we usually never "Copy projects > into workspace". That way the workspace folder only contains meta data. We > delete the whole folder, when starting from scratch. > > Also, did you restart Eclipse between your test-runs? The > ExternalFoldersManager seems to be a singleton so it probably cached the > external directory entries. No luck with those either. Thanks for the suggestions, though.
Olivier, what do you think? Can I go ahead and release the patch?
(In reply to comment #18) > Olivier, what do you think? Can I go ahead and release the patch? The patch doesn't seem to hurt anyway and the reporter confirmed it fixed the issue. Once Ayushman approved it, you can release it.
Jay, the attached projects for the regression test to run have been mis-attached as a patch. I'm guessing you intended to provide a zip file or jar file? Can you please re-attach? Thanks! Otherwise, the patch looks good, though I don't how it works.
Comment on attachment 188591 [details] Test projects Sorry, the attachment is a ZIP and not a patch.
Looks good.
Released in HEAD for 3.7M6.
I couldn't reproduce it either. However, as it works for the bug submitter and not able to reproduce the problem with 3.7M6, am marking it verified. Verified for 3.7M6 using build I20110307-0800
