Community
Participate
Working Groups
The original intent of capabilities (abilities) was to allow each product to provide their own definitions based on the desired breadcrumbs and workflow in the specific product. In reality, every product I see copies and redefines the capabilities from the products/SDKs beneath them, rarely changing them other than changing the default enablement. Almost all capabilities tend to be component based, but instead of defining them with the component they are defined in the SDKs or product plugins of several downstream products. This leads to the following issues: * No extension or reuse of capabilities; every product defines their own. * Bugs because the capability is being defined by someone outside of the component team, or copied from elsewhere. Someone on the product must own capabilities for external components. * Bugs with capability definitions must be fixed in multiple places/products. * Single place where capabilities are defined, making it harder to coordinate and assign ownership on larger teams. This enhancement request is to support a mode where one or more capabilities can be defined by each component, but products/SDKs still control how it is displayed in the UI - e.g. the default state, categories, or combining multiple capabilities as one selection in the UI. As an example, teams like PDE and EMF would each define their own capability and be responsible for testing and maintaining it, but as a product I could decide to leave them as-is, or combine both into a single 'Eclipse development' capability (or maybe just category?) and turn it off by default (sorry guys). I want to keep things simple, and I'm willing to believe there is another solution. Hopefully this bug will start the discussion and come up with changes or new recommendations for Eclipse 3.4.
You can do most of what you want to do already. You can define the capability separate of the category and enablement state - they are all done by separate elements. Combining two capabilities isn't easily achieved at the moment but I'd entertain ideas of how that might work. Keep in mind that time for new API in 3.4 is rapidly dwindling and we don't currently have any time allocated for further work on capabilities. A concise explanation of what you'd like this to look like would be helpful.
Ok, sorry for the delay. What I'm asking is this: 1. Move capabilities for the Eclipse platform from source features into the regular features so that they can be reused and are part of the 'install' of the base platform. Other projects would hopefully take this lead or I'll follow up with other bugs. 2. Whether this release or not, some adopter will eventually disagree with these 'default' capabilities. We either need to make a design decision that capabilities are now component based and everyone needs to live with these, or start allowing capabilities to be overridden. In the simplest case it would just be an extension point to remove a capability or override it with another.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
