Bug 150404 - [CommonNavigator] CDT Projects appear twice
Summary: [CommonNavigator] CDT Projects appear twice
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P1 critical with 1 vote (vote)
Target Milestone: 3.3 M7   Edit
Assignee: Michael D. Elder CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 179838 (view as bug list)
Depends on: 142330
Blocks: 170090
  Show dependency tree
 
Reported: 2006-07-12 11:36 EDT by David Daoust CLA
Modified: 2007-05-03 06:30 EDT (History)
7 users (show)

See Also:


Attachments
Avoid duplicate projects in Common Navigator (2.81 KB, patch)
2006-07-13 05:04 EDT, Anton Leherbauer CLA
no flags Details | Diff
Patches o.e.cdt.ui and o.e.jdt.ui (14.46 KB, patch)
2007-04-24 23:29 EDT, Michael D. Elder CLA
no flags Details | Diff
Fixes refresh of IJavaProject --> IProject; required for bug 156202 (14.75 KB, patch)
2007-04-25 00:05 EDT, Michael D. Elder CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Daoust CLA 2006-07-12 11:36:24 EDT
With the new changes to the common navigator support for CDT, the CDT projects now appear twice in the the ProjectExplorer (which I added to the default C/C++ perspective for testing).   The first appearance does not have the CDT specific content (containers and file contents), while the second does.
Comment 1 Anton Leherbauer CLA 2006-07-13 04:06:25 EDT
Yes, that's a known issue. It's actually the JDT extension which duplicates the projects. If you disable the JDT extension (View menu > Filters), the duplicates disappear. I will reroute this to JDT and provide a patch.
Comment 2 Anton Leherbauer CLA 2006-07-13 04:21:16 EDT
Rerouting to JDT. I am not quite sure if JDT is the actual owner of the Common Navigator extensions. Please reroute again if you think it belongs somewhere else.
The issue can be replicated with one of the nightly builds of CDT 4.0 which you can find at http://download3.eclipse.org/tools/cdt/builds/4.0.0/index.html
Comment 3 Anton Leherbauer CLA 2006-07-13 05:04:53 EDT
Created attachment 46227 [details]
Avoid duplicate projects in Common Navigator

This is is the proposed solution. The same strategy is implemented in the CDT extension.

If a project has both Java and CDT nature, the project will still be duplicated, but in this case the duplication is somewhat "natural" because each project node shows its nature-specific content. Ideally, both natures would share one project node and add only their nature-specific content, but I suppose this is not so easy.
Comment 4 Doug Schaefer CLA 2006-07-13 09:54:48 EDT
Yes, I'd much prefer to have one project node that the JDT and CDT can add content to. Having the project listed twice will just confuse the user, or at least continue the perception that we aren't really working together.

I continuously get requests for better support for JNI programming so whatever we can do as a team to make this better will be a huge plus for Eclipse.
Comment 5 Martin Aeschlimann CLA 2006-07-13 16:47:53 EDT
Michael, let me know if you want me to release the patch provided in comment 3.
Comment 6 Michael D. Elder CLA 2006-07-13 17:08:09 EDT
Does the CDT use some form of "ICDTProject" in your extension?

In both cases, the JDT and CDT want to override the complete representation of the project. For both extensions to be available under a JDT/CDT project, one of the two extensions must "yield" to the other, and add their content to the IJavaProject/ICDTProject. This will require some minimal coordination, particularly in choosing the relative priority of the extensions as that affects which has the opportunity first to "override" the content of the other. 

If you take a look at the WebJava extension in org.eclipse.jst.j2ee.servlet.ui, you'll find an example where the Java rendering is "re-written" for Web projects, to make it a little friendlier for non-Java developers. The JDT/CDT might choose to use a similar pattern for a JDT/CDT project. In this scenario, one extension would choose to simply add content, rather than replace the base model type representing the project. 

Martin -- The basic idea of the patch is on the right path. I'll take a look at the patch in more detail and let you know. 
Comment 7 Anton Leherbauer CLA 2006-07-14 09:11:08 EDT
(In reply to comment #6)

Instead of a "master" and "slave" approach (we all know who would be the master ;-) I had actually a more democratic approach in mind, where both *DTs contribute independently to a common project node (IProject). But maybe your approach is more realistic.
Anyway, thanks for the hint!
Comment 8 Michael D. Elder CLA 2006-07-14 09:22:05 EDT
In the original WTP framework, IProject was the standard. For various reasons, we were encouraged to allow extensions full control to replace items in the tree as they needed for their existing models. 

Comment 9 Michael D. Elder CLA 2006-07-19 16:26:44 EDT
A change to the core framework to facilitate this cannot be made safely for 3.2.1. Deferring to 3.3.
Comment 10 Michael D. Elder CLA 2006-07-19 16:26:57 EDT
A change to the core framework to facilitate this cannot be made safely for 3.2.1. Deferring to 3.3.
Comment 11 Anton Leherbauer CLA 2006-12-15 08:46:07 EST
Is there any progress?
Comment 12 Martin Aeschlimann CLA 2007-02-12 05:58:48 EST
Michael, this has high priority, can you have a look?
Comment 13 Anton Leherbauer CLA 2007-03-29 07:17:30 EDT
*** Bug 179838 has been marked as a duplicate of this bug. ***
Comment 14 Doug Schaefer CLA 2007-03-29 10:07:51 EDT
Hi there, I see this tagged as target milestone 3.3. I'm just checking to make sure that this isn't going to drop from 3.3 given that it's getting late. We've been hoping to use the common navigator in the C/C++ perspective, but haven't been able to due to this issue. Thanks.
Comment 15 Michael D. Elder CLA 2007-04-24 23:29:04 EDT
Created attachment 64825 [details]
Patches o.e.cdt.ui and o.e.jdt.ui

The patch modifies the C and JDT extensions to use IProject as their common format. The children are still model specific.
Comment 16 Michael D. Elder CLA 2007-04-24 23:31:32 EDT
Please apply and verify the patch with your function. I don't have the latest C/CDT code in my environment, but for all of the tests I tried it was working fine. I noticed a bug where "New > [C] Source Folder" didn't add a C element source folder; but the behavior was consistent with the C/C++ project explorer. I tracked it down to the singleton Core Model not being updated with the most recent set of Source Roots when the navigator extension attempts to convert the add request in CNavigatorContentProvider.interceptAdd().
Comment 17 Michael D. Elder CLA 2007-04-25 00:05:16 EDT
Created attachment 64826 [details]
Fixes refresh of IJavaProject --> IProject; required for bug 156202


This patch has been updated to convert refresh events for IJavaProject to IProject. It will be required for the fix for bug 156202.
Comment 18 Martin Aeschlimann CLA 2007-04-25 04:00:21 EDT
JDT patch released > 20070425
Comment 19 Anton Leherbauer CLA 2007-04-25 05:53:55 EDT
Applied CDT part to HEAD.
Comment 20 Michael D. Elder CLA 2007-04-25 09:13:39 EDT
Patches have been applied. 
Comment 21 Karsten Becker CLA 2007-05-03 05:32:52 EDT
Starting verification
Comment 22 Karsten Becker CLA 2007-05-03 06:05:12 EDT
verified in I20070502-0010
Comment 23 Martin Aeschlimann CLA 2007-05-03 06:30:18 EDT
.