Community
Participate
Working Groups
1. Create working set and make it top element in the project explorer 2. Link Project Explorer with Editor 3. Create Java projects A, B, where A depends on B, and add them to working set 4. Create interface in B, and a class implementing that interface in A. Close editors, collaps B project. 5. Open the class, select the interface and press F3. Project B is not expanded.
This has been fixed in 3.5RC7, but the fix has to be backported to 3.4.2.
(In reply to comment #1) > This has been fixed in 3.5RC7, but the fix has to be backported to 3.4.2. > As far as I know there are no further releases in the 3.4 line, so there is really nothing that can be done about this. Please reopen if I'm wrong.
You are right. But adopters still use that branch, and they can build on their own (look f.e. at http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES). I do understand that you may not work on this, just give me some clues and will figure out sooner or later how to fix this :-)
(In reply to comment #3) > You are right. But adopters still use that branch, and they can build on their > own (look f.e. at http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES). > > I do understand that you may not work on this, just give me some clues and will > figure out sooner or later how to fix this :-) > I remember this problem and just spent the last 20 mins or so looking through the fixed bug reports and can't seem to find it. This actually might have been a JDT UI configuration problem (with the CNF) now that I think about it. If you look at the history of plugin.xml in the JDT UI for maybe 3.5M5-M7 you might see a change in the CNF configuration that I think might have been the thing that fixed this. I looked through the JDT UI bugs though and also could not find it. I'm sorry I can't be more helpful, but that's all I can remember for the moment. Let me know if this does not work out and perhaps I can do some more digging. If you find the bug, please dup this against it.
Moving to Common Navigator so that you can continue the conversation there ;-)
(In reply to comment #4) > If you find the bug, please dup this against it. Looks like bug 215729. Note that this bug has probably been fixed by the fix for bug 275847.
The bug is quite similar, but 3.4.2 stream already contains patch attached to 275847. The issue was fixed somewhere in 3.5M7
> Looks like bug 215729. > Note that this bug has probably been fixed by the fix for bug 275847. This is exactly the bug I was thinking about when I made the above comments. I'm not sure both patches are the same (if they are it would surprise me that bug 215729 is still open). Dani, do you know anything about this?
>The bug is quite similar, but 3.4.2 stream already contains patch attached to >275847. The issue was fixed somewhere in 3.5M7 No it does not. *** This bug has been marked as a duplicate of bug 275847 ***
>>The bug is quite similar, but 3.4.2 stream already contains patch attached to >>275847. The issue was fixed somewhere in 3.5M7 >No it does not. To clarify in case it is not clear: 3.4.2 or R3_4_maintenance does not contain that fix.
*** This bug has been marked as a duplicate of bug 275847 ***
Right, the patch was not there. So I have applied the patch to 3_4_maintenance, tested a little bit more carefully, and even with that patch I am able to reproduce the issue. It looks like CN is not able to look into the JavaProject to show any element that was not shown before. So as long as your projects are not expanded when Eclipse starts, link with editor will not work.
Obviously some cases (see bug 275847 comment 2) are fixed. Can you provide step-by-step test case(s) where it does not work? Also, are those really fixed in 3.5RC7?
So far reproduction steps from bug description are still valid. I know you are quite busy with RCs you may not find time to play with 3.4.2. I have enough input to try to solve this on myself :-). If I'll stuck or need help, I'll ping you.
Project Explorer ignores "link editor" as long as target project remains collapsed. If the project is expanded (it shows the src folder), files will be revealed correctly. If the files were previously visible, everything works correctly. I have found that NavigatorContentServiceContentProvider#getParents returned different paths according to whether the src folder is visible (Java Project is expanded) or not. (I) Java Project Expanded R/ | P/JavaP2 | src [in JavaP2] <default> (...) com (...) com.ibm (...) | com.ibm [in src [in JavaP2]] [Working copy] IFoo.java package com.ibm interface IFoo --------- R/ | P/JavaP2 | src [in JavaP2] <default> (...) com (...) com.ibm (...) (II) Java Project Collapsed --------- R/ | P/JavaP2 | src [in JavaP2] <default> (...) com (...) com.ibm (...) | com.ibm [in src [in JavaP2]] [Working copy] IFoo.java package com.ibm interface IFoo | --------- R/ | P/JavaP2 | src [in JavaP2] <default> (...) com (...) com.ibm (...) | --------- R/ | P/JavaP2 | --------- R/ | --------- (empty path) Assuming that R/ means workspace root, are those paths correct? I mean Root/Project/CU while Navigator displays something like Root/WorkingSet/Project/CU?
Francis, can you answer this?
(In reply to comment #16) > Francis, can you answer this? > Yes, give me a couple more days, I'm pretty busy right now.
Reopening (see comments 12 & 15), because some work still needs to be done here.
>So far reproduction steps from bug description are still valid. Not really, because the key is that the project must have never been expanded before. I can reproduce if I restart after step 4.
The bug is that in case of Java working sets, the Project Explorer renders Java projects instead of resource projects which it does in all other cases. This of courses causes troubles because the JavaNavigatorContentProvider returns an IProject when asked for the parent of a (Java) project's child. If we put the Java projects into a resource working set then it works just fine.
Created attachment 138920 [details] Fix
Francis, can you please double-check my findings and review my patch.
Created attachment 138927 [details] Fix for 3.4.2
Krzysztof, can you verify that this fixes your issue?
Patches solve the issue. Thanks Dani.
*** Bug 267986 has been marked as a duplicate of this bug. ***
Thanks Dani for working on this, I will review it next week. I"m still swamped with my day job this week. And nice that it fixes the CVS hostname issue as well.
Looks good Dani, thanks for doing this. Unless you object, I will go ahead and check release this to HEAD and 3.5.1 (I think 3.5.1 is open for us now).
Don't worry, given the bug is assigned to me I'll take care of this.
That's great, then you will do my version bumping for me as well?
Yep.
Fixed in HEAD for 3.6 and updated the bundle version and filed bug 281462 to look into the required bundle versions: I doubt it will ever compile or run with those.
Fixed in R3_5_maintenance.
Created attachment 140764 [details] TestFix 3.4.x
Verified in I20090826-1100.
