Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #252807 +++ Each project will provide basic capability/activity definitions to allow for their UI contributions to be hidden. These must be provided in a separate plugin/feature to facilitate inclusion/exclusion by consumers in product development.
This will require the following work for the SDK: 1) an audit of all actionsets currently not bound to an activity. Paul, I understand this has been done but I can't remember who you said did it. 2) the creation of several new plugins. I would suggest 4 - jdt.capabilities, pde.capabilities, team.capabilities, and ide.capabilities. The two development activities would go in pde/jdt.capabilities, while all the Team ones would go into team.capabilities. The development category would go into ide.capabilities along with the update capability (although there could be argument for this to be included in an update.capabilities bundle as well). the ide.capabilities would also contain some new activities (potentially) that actionsets defined in base IDE plugins would be bound to. There could be other ways in partitioning this work but in the absence of any guidance from the planning council this seems like a reasonable way to go.
(In reply to comment #1) > This will require the following work for the SDK: > > 1) an audit of all actionsets currently not bound to an activity. Paul, I > understand this has been done but I can't remember who you said did it. Prakash did that work, bug 248562 PW
Hi Kim, cutting and pasting from an email I have: > Activities are already provided by the Eclipse SDK (Window -> Preferences -> > General -> Capabilities) (The "Advanced" button on that dialog brings up full > list.) > Those activities are defined in the org.eclipse.sdk plugin included in the > "Eclipse Project SDK" feature. These are sufficient for now, no?
(In reply to comment #3) > These are sufficient for now, no? Who am I to disagree? ;-) We would like to complete our current story, but plan no big changes. See bug 248562 for details.
Ant and Debug plan to make the change in M6, so I am moving this one to M6 as well.
The changes for Ant and Debug have been released to CVS. Oleg, could you have a look once this shows up in the builds, for example in the next I build?
Created attachment 125672 [details] Screenshot of new capabilities
Verified that new capabilities are present in the I20090211-0900 build.
I was surprised to see this closed as "fixed", since as far as I can see it does not meet the part of the requirement that says "These must be provided in a separate plugin/feature to facilitate inclusion/exclusion by consumers in product development." As described in detail in http://wiki.eclipse.org/Galileo_Capabilities Were the plugins described in comment #1 created, and I'm just missing them? "2) the creation of several new plugins. I would suggest 4 - jdt.capabilities, pde.capabilities, team.capabilities, and ide.capabilities. " One use-case I'm thinking some adopters might want (and I do mean might ... I know of no concrete case and am just mentioning this as an illustration) would be that they'd want a primarily-XML-IDE product, but for the sake of some users might want to included JDT, but "hide" the JDT functionality for the majority of their users. Sorry if I'm just missing it, but if I have an accurate view, I think better to mark as 'won't fix' and have an explicit exception for Galileo (with a promise of future improvements :) I encountered this because I was trying to figure out how to enable capabilities in the Java EE IDE package, and didn't seem right to include the whole eclipse-sdk plugin ... since there's extra stuff in there, and some things are "hard coded" (enabled, or not, for example). I tried to copy/paste some of the "extensions" but it's very confusing, and haven't gotten that to work yet. What would the Eclipse Project recommend for the Java EE IDE?
(In reply to comment #9) > Were the plugins described in comment #1 created, and I'm just missing them? The discussion in the bug 252807 eventually evolved into saying that is it *recommended* to create new plugins *if* the component does not define capabilities already (bug 252807 comment 36). Similar text is on the wiki page. Moreover, we tried to clarify this specific question and it was my understanding that there is no need for those separate plugins - see comment 3. That said, if it turns out that there is a need for separate plugins, we probably could create them for 3.5.1. > I encountered this because I was trying to figure out how to enable > capabilities in the Java EE IDE package ... Hmm, the irony :-). There are quite a few comments on the bug 252807 trying to get a clear picture on how that is going to work from the originator of this request, the Planning Council. In this particular case, say, if we had a separate plugins with JDT and PDE capabilities, how would that help? Their plugin.xml's would have to have all capabilities enabled (dictated by SDK downloads). You could modify PDE capabilities plugin to disable its activities, but what happens when the end user runs Update and replaces your modified plugins with ver.1.1 PDE capabilities plugin.
(In reply to comment #10) > (In reply to comment #9) > > In this particular case, say, if we had a separate plugins with JDT and PDE > capabilities, how would that help? Their plugin.xml's would have to have all > capabilities enabled (dictated by SDK downloads). You could modify PDE > capabilities plugin to disable its activities, but what happens when the end > user runs Update and replaces your modified plugins with ver.1.1 PDE > capabilities plugin. > I'll have to read the bug you referenced and see if there's "hints" on how to solve for my case ... didn't know that was there (or forgot) ... so, thanks for the pointer. But, I think I can answer this last question you asked ... it's not so much having separate plugins ... that part might be a good idea, but maybe not essential ... but I thought the essential part was to have one plugin with the activities defined but leave the default activation and categories up to the _product_ plugin. So for eclipse sdk, yes, you could always activate them by default. But in JEE IDE product package we might not enable, say PDE. And the JEE IDE would not include the "eclipse sdk product" plugin, so would not be updated or overwritten in future updates. Hope that helps, but yes, I'll read back ground a little better and see what I missed (or am forgetting). Thanks again.
I've read the background bug 252807 referred to, and we've definitely lost the forest for the trees. To me, the main points was that Eclipse _products_ should be able 1) to include or leave out another project's capability definitions, depending on whether or not they included that projects function. 2) if including another project's capabilities, have some say on if it is enabled by default and what the categories of capabilities are. So, you, the Eclipse Project don't meet either of these. The first because to leave out the eclispe.sdk plugin (where the definitions reside) means the product would also leave out other things ... like the capabilities preference page! Rich sort of mentioned this in comment https://bugs.eclipse.org/bugs/show_bug.cgi?id=252807#c32 but don't think he went far enough. The second because you do specify the default state and categories for your capabilities. [I do think that's the one everyone was willing to be flexible on, for this release]. But, yes, Anthony was wrong in #3 and Boris too eager to agree in #4. :) I think "2" above was what led to a lot of the complex discussion in bug 252807 and is what led to people thinking "well, do the best you can" sort of conclusions. And, I agree, as a group, we still don't agree on all the right answers there. And, you, the Eclipse Platform are really the only one effected by "1" since you are the only one (as far as I can see) that have coupled your capabilities definitions with other, unrelated functionality (your branding, and the preference page for capabilities itself, and a couple other things in there, I think unrelated to the capability definitions). So, obviously long and short term issues here, but let me verify if my use case is clear to you. Imagine I want to create some IDEs that do not have PDE and maybe some even without Java! But I still want a capability preference page and capabilities from other projects and functionality. One common example is an "xml only" ide (which can be pretty complex, xml, xsd, dtd, xsl, and much more, but no java and no pde). Another example is "web only" ide, with HTML, JavaScript, CSS XML, etc, but no Java, and no PDE. How do I do that? That's question one. Maybe we'll get to other questions once I understand that, since I'm probably missing something fundamentally easy that you can explain to me. Are my use-cases clear?
(In reply to comment #12) > But, yes, Anthony was wrong in #3 and Boris too eager to agree in #4. :) Just for the record, it's not that the Platform UI team hadn't tried, before those comments, to get some clarity about what the intentions of the Planning Council were, see the discussion in bug 252807 comment 1 to bug 252807 comment 31. I guess we should have asked for concrete use cases specifically... > And, you, the Eclipse Platform are really the only one effected by "1" since > you are the only one (as far as I can see) that have coupled your capabilities > definitions with other, unrelated functionality (your branding, and the > preference page for capabilities itself, and a couple other things in there, I > think unrelated to the capability definitions). Yes, but all of these things would be replaced by a product-specific plug-in that replaces ours, see the end of this comment for details. Note that the Eclipse Platform also has a separate download with "just the platform", i.e. no JDT or PDE, called "Platform Runtime Binary" or "Platform SDK". This download comes with different branding ("Eclipse Platform", not "Eclipse SDK") and does not include the preference page. This was done intentionally, so that downstream products can add their own preference page or other mechanism for changing which capabilities are enabled, or so that downstream products can control this through other means. Neither org.eclipse.sdk nor org.eclipse.platform, the two plug-ins containing branding etc. were ever meant to be taken as is when someone builds a product on top of the Eclipse IDE. > So, obviously long and short term issues here I do hope that there are no short term issues... or do you want us to change this for 3.5.0? > but let me verify if my use case > is clear to you. Imagine I want to create some IDEs that do not have PDE and > maybe some even without Java! But I still want a capability preference page and > capabilities from other projects and functionality. One common example is an > "xml only" ide (which can be pretty complex, xml, xsd, dtd, xsl, and much more, > but no java and no pde). Another example is "web only" ide, with HTML, > JavaScript, CSS XML, etc, but no Java, and no PDE. > > How do I do that? That's question one. Maybe we'll get to other questions once > I understand that, since I'm probably missing something fundamentally easy that > you can explain to me. > > Are my use-cases clear? I think they are, thank you for making this much clearer than before. To answer your question about the "xml only" IDE, you would take a close look at the org.eclipse.sdk plug-in and its plugin.xml and then create a similar plug-in replacing it, containing: - your product's branding (splash screen, about dialog branding, etc) - your product's welcome page definition - a copy of the activity definitions, or a subset thereof, as required - a definition of what your "primary wizards" are - these are the wizards that can trigger enablement of capabilities that were not enabled at the start - a definition of the capabilities preference page, if required - note that the code for this is in another plugin, we are talking about 15 lines of XML for the extension definition in the plugin.xml - a definition of the "trigger point advisor" - again, you can just use the implementation of that provided by the workbench if that's good enough - other stuff that is product-specific, e.g. a list of search engines that will appear in the help system. I am sure that *all* IDE-like products built top of the Eclipse IDE replace this plug-in with their own, at least so that they get appropriate branding. As far as I know, it is common for such products to *not* include the preference page and to replace it with other mechanisms for customizing the UI (e.g. fixed enablement for capabilities, or a mechanism that appears at a more prominent place such as the the welcome page). They would also typically list different primary wizards, and potentially different capabilities and their enablement. Not sure if it would be worth creating six separate plug-ins to separate out the capability definitions (a few lines of XML each for "Development/Java", "Development/Ant", "Development/Debug", "Development/Plug-in Development", "Team/Core Team Support", and "Team/CVS"), plus maybe two extra plug-ins for the categories "Development" and "Team", but if this is important, we can probably do it for 3.5.1.
David, is this something that you are looking for as a goal: - Features declare activities - either in a sepate plugin or not, does not matter; - Product in its brading plugin creates categories and specifies enablement? If that is what you are asking for, when for SDK it could be implemented in two ways: a) Split part of org.eclipse.sdk that defines activies into a separate plugin - org.eclipse.sdk.activies, or b) Split parts of the org.eclipse.sdk that defines activities into the corresponding features moving pieces of the XML into Ant, Debug, JDT, PDE, Update, Team, and CVS plugins. Just to establish a goal, would (a) or (b) work for you, or would you like to get something else as a result? ==== Now, to muddy the water :-), let's keep in mind that the primary goal of activities was to provide an end user with a way to gradually discover advanced features. I think that this aspect was totally overlooked so far and replaced with a desire to use activities to get rid of unwanted UI elements. Which is a somewhat different task. Using activities for the task of removing unwanted UI contributions is *not* the best choice: - we'll run into problems with discovery mechanisms (where should they be defined? product or contributing feature?); - granularity: everybody has their own opinion on what should or should not be removed. I'd like about 75% of the popup menu items to be removed; activies won't solve it; - removals are only part of the game; how about moving menu items around or changing the text?
We're not going to do anything more here for 3.5, so I'm marking fixed. Alternatively David we can mark it WONTFIX if you prefer. I think we are doing the correct thing by bundling our capabilities with other product branding that is not intended to be reused. We may be unique in the release train in contributing a product to the train, so perhaps the guidelines need to clarify this in the future. I don't see much value in making our capabilities reusable independently from our other branding elements - capabilities were always intended as a product-level notion, and other larger products that consume the platform will generally need to override both the capabilities and the other branding elements defined in org.eclipse.sdk.
(In reply to comment #15) > We're not going to do anything more here for 3.5, so I'm marking fixed. > Alternatively David we can mark it WONTFIX if you prefer. Thanks John. Apologies for not getting back sooner ... I was hoping to wait until I could try and "duplicate" the capabilities preference page, the help contributions made in eclipse.sdk, and the capability definitions themselves ... but haven't been able to get back to re-working all that. I'd sort of prefer 'wontfix' to help emphasize the planning council's lack of clarity, and the ongoing issues that need to be addressed still ... but, I know some people think of that as a negative thing so I won't insist. I believe you are all sincere in thinking you are doing what you think you should be doing ... just not sure everyone agrees you are doing what the PC requested (and your PMC representative agreed to). Thanks to everyone's comments ... let's start again for Helios ... much earlier in the cycle.
I finally did get around to reuse-by-copy-paste, taking the "branding" stuff out of eclipse.sdk and copying to a epp.package.capabilities plugin. Seems to be working fairly well in latest Java EE package, but I've a couple of urgent questions, which hopefully can be answered here in this bug. The eclipse sdk plugin.xml contained a few things besides branding and capabilities. Are they things I should copy in Java EE package? Are they things that would hurt if I copied them? Current Java EE build has them copied. 1. java wizards? I can't imagine why these are in eclipse.sdk, instead of a java.ui plugin ... but I don't want to "lose" function compared to Elcipse SDK. <extension point="org.eclipse.ui.newWizards"> <primaryWizard id="org.eclipse.jdt.ui.wizards.JavaProjectWizard"> </primaryWizard> <primaryWizard id="org.eclipse.pde.ui.NewProjectWizard"> </primaryWizard> <primaryWizard id="org.eclipse.jdt.ui.wizards.NewClassCreationWizard"> </primaryWizard> <primaryWizard id="org.eclipse.jdt.ui.wizards.NewInterfaceCreationWizard"> </primaryWizard> <primaryWizard id="org.eclipse.ant.ui.wizards.JavaProjectWizard"> </primaryWizard> </extension> 2. Help additions. I'm pretty sure it would not hurt to also copy these, but I can not imagine (again) why these are in eclipse.sdk and not in a help.ui plugin. <extension point="org.eclipse.help.ui.searchEngine"> <engine enabled="true" engineTypeId="org.eclipse.help.ui.web" id="org.eclipse.sdk.Google" label="%search.Google.label"> <description> %search.Google.desc</description> <param name="url" value="http://www.google.com/search?hl=en&q={expression}&btnG=Google+Search&meta="> </param> </engine> <engine enabled="true" engineTypeId="org.eclipse.help.ui.web" id="org.eclipse.sdk.Eclipse" label="%search.Eclipse.label"> <description> %search.Eclipse.desc</description> <param name="url" value="http://eclipse.org/search/search.cgi?q={expression}&ul=&ps=20&m=all"> </param> </engine> </extension>
Created attachment 139602 [details] Team Project set for Java EE IDE capabilities plugin If anyone is interested, and quick reviews would be appreciated if anyone is so motivated, the attachment will pull in what we are using in Java EE IDE as our "pure capabilities" plugin. I realize without good triggers, they are of limited usefulness, but hopefully Galileo will be a small step forward and motivate improvements next release. Bug 280566 documents some of the "hassle" of this copy/paste method of re-use. And, just to cross reference, bug 235039 documents the (long standing) problem of providing distributions without a Capabilities Preferences page.
Re comment 17: Those definitions are at the SDK level as they are considered product (say SDK) customization i.e. the product decides what wizards are the most important ones instead of letting every component (like JDT or Help) decide by itself. This also prevents cluttering because every component might think it is the most important one ;-) Moving those definitions is not a problem (just make sure you also copy the NLS strings and images if any). You can even copy the primary wizard definitions as duplicates will be ignored but with the search engine you have to be careful as those will not ignore duplicates and hence appear twice (or more if copied even further).
