Bugzilla – Full Text Bug Listing
| Summary: | Confusing debugger capabilities | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Anton Leherbauer <aleherb+eclipse> | ||||
| Component: | cdt-debug | Assignee: | Ken Ryall <ken.ryall> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Ken Ryall <ken.ryall> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | mober.at+eclipse, pawel.1.piech, vivkong | ||||
| Version: | 7.0 | ||||||
| Target Milestone: | 7.0 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Anton Leherbauer
I would even claim that these CDT capabilities are a major problem for our product on top of Eclipse / CDT. And that these should be removed NOW, before somebody starts relying on these capabilities existing in a place where they should not be. Here is the reason why I think this is a major problem: In our product on top of Eclipse, we have created a set of Capabilities that matches our needs, such that we can hide things that we don't want to expose to a user. But since Eclipse Capabilities work such that any one item is ENABLED as soon as ONE activity that matches its pattern enables it, our mechanisms don't work any more: stuff gets enabled by the CDT capabilities, although we want to deliberately hide it. Long story short, the biggest problem is Toni's point 2: Capabilities must be defined in the context of a PRODUCT, and not in the context of a plugin or component. I would recommend removing those capability definitions from the code completely and only document on a webpage what can be enabled in order to satisfy the Helios requirement; WTP, for instance, has moved in this direction as per bug 306315 comment 13, and http://wiki.eclipse.org/WTP_Capabilities_Helios Or, to define the capabilities in a separate plugin which product builders can safely remove from their product config; like the Eclipse SDK defines its Capabilities in the org.eclipse.sdk bundle which adopters of the plain Platform typically don't use. Or like Mylyn does, as per bug 299344 comment 16. In the context of contributing Capabilities to the EPP packages, also http://wiki.eclipse.org/Helios/Contributing_to_Helios_Build#Contributing_non-categorized_bundles_or_features_to_the_central_repository may be relevant here. Fair enough, I'll go back, look at all these again, and pull them out if I can't satisfy your concerns. Thanks Ken! My acceptance criterion is simple: Regardless of structure, any Capability definition must be in some palce that I can safely not use when building my product... those Capability definitions that I need will then be properly merged into my own product / branding bundle. All activities have been moved to org.eclipse.cdt. Categories have been removed as they didn't make sense and these didn't need to be user visible anyway. Created attachment 170037 [details]
the changes
Interestingly, I cannot see anything related to Capabilities in the plugin.xml of org.eclipse.cdt -- am I missing something? This is where I am looking: /cvsroot/tools, org.eclipse.cdt-releng/org.eclipse.cdt and CVS tags seem to indicate that this is the current version... I added them to org.eclipse.cdt/all/org.eclipse.cdt because that's what I had in my workspace. Not sure how this is different than org.eclipse.cdt-releng/org.eclipse.cdt. *** cdt cvs genie on behalf of kryall *** [!] plugin.xml 1.248 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/plugin.xml?root=Tools_Project&r1=1.247&r2=1.248 [!] plugin.xml 1.20 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf.ui/plugin.xml?root=Tools_Project&r1=1.19&r2=1.20 [!] plugin.xml 1.38 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/plugin.xml?root=Tools_Project&r1=1.37&r2=1.38 [!] plugin.xml 1.13 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt/plugin.xml?root=Tools_Project&r1=1.12&r2=1.13 [!] plugin.xml 1.35 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.mi.ui/plugin.xml?root=Tools_Project&r1=1.34&r2=1.35 Ok, I'm getting the updates now - thanks. Apparently the pserver shadow copy was lagging on dev.eclipse.org. (In reply to comment #4) > All activities have been moved to org.eclipse.cdt. Categories have been removed > as they didn't make sense and these didn't need to be user visible anyway. Hi Ken, so how can users activate the preference pages hidden by capabilities now? I'm asking from a translation testing point of view. Thanks (In reply to comment #10) > (In reply to comment #4) > > All activities have been moved to org.eclipse.cdt. Categories have been removed > > as they didn't make sense and these didn't need to be user visible anyway. > > Hi Ken, so how can users activate the preference pages hidden by capabilities > now? I'm asking from a translation testing point of view. Thanks They are activated when they first launch a debug session for DSF-GDB, CDI-GDB, or DSF-EDC. |