Community
Participate
Working Groups
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.
Activities, from the get go, were intended to be a solution driven from the top down. This doesn't necessarily mean that there is some expert that crafts the activity solution set for the entire product (although I can dream), but there needs to be some direction with regards to ontology, granularity, and even nomenclature. Remember, these things are meant to assist novice users in exploring the functionality of their Eclipse-based product. A hodgepodge of activites, each of which follows it's own rules and norms, probably wont help anyone. It would be helpful to understand the context in which this bug was created. What is the result we're trying to achieve here? Some questions that might help us figure that out: What is the intended granularity of these capabilities? Are we aiming for a 1-1 mapping between project (for some value of project) and activity definition? Are we looking to be more granular than that, targeting specific features (lowercase) within a project? What about the structure of the ontology itself? Should each project construct it's own hierarchy of activities/categories or will they be expected to fit within one defined from the top? ie: the Development Category, the Team category, the Data category, etc. Will/should the structure be based on functionality or expected user roles? If we're talking about the former there's some hope that individual teams will be able to make the right decision (provided they receive guidance on the above questions) but if the intention is for the later there is going to need to be a lot of inter-team negotiation and understanding, not to mention a lot more work from someone at the top who understands what roles users in Galileo might take.
Rich, Could you help us understand the context of this requirement? Should Kim's questions be brought to the Planning Council's attention?
When we drafted this requirement, we expected there to be a long discussion to follow, so thanks for starting it. I've added it to our next call agenda: http://wiki.eclipse.org/Planning_Council/Dec_03_2008 Our discussion at the f2f left us with pretty low expectations for the outcome, frankly. At a minimum, we felt it would be valuable for consumers to have a set of starter capability definitions from each project, or more specifically, each major feature set. With that, they would be delivered separately so as to avoid the problems Kim mentions until such time (if ever) we wanted to go to the next level of role-based capability definition. On a related topic, the composition of SDKs was also discussed, resulting on this wiki page I'd appreciate some feedback on: http://wiki.eclipse.org/SDK_Composition
As the guy who championed this new "must do", I thought I would post an email I saved about this. --------------------------------------- Things are progressing here, and I have what may be a stupid question, but I can't seem to find the answer via google or online help anywhere.... Lets assume that I ship the first release of this product I'm working on as a eclipse platform application, rather than an RCP. Given the numerous dependencies on EMF, GEF, GMF etc that I'll have how do I disable/remove their contributions to the File->New menu? My reasoning is that I really don't want to confuse the user with wizards they should not be looking at or using... Any ideas on where I can look for examples on how to do this? ----------------------------------------- The obvious answer for the customer is to take advantage of capabilities in Eclipse. I know several teams have provided example capabilities, such as the platform and EMF, but they are just that, examples. Trying to get a set of working capabilities without the knowledge of how everyone's plug-ins and features fit together is not a fun task. As part of our Galileo packages, wouldn't it be nice if we provided some out of the box, fully functioning capabilities to do just what our Eclipse customers are asking for. What parts should and should not be active when I am a C++ developer or a PDE developer? What are the advanced features? Do I need an extra capability to allow the end user to turn off the advanced features? And by coming up with a proper set of capabilities, we will be able to do a little better job of integration testing and be able to turn off the tens of contributions to file -> new. I do not think coming up with one or two capabilities for each Galileo component is very difficult.
Hi, I think I am missing context. I don't understand what you mean by capabilities. Could you please define what you mean by capability/activity definitions ? I asked around on our project mailing list[0], and apparently others are also puzzled by this. [0]: http://dev.eclipse.org/mhonarc/lists/stp-dev/msg02104.html
Kim has a blog entry which illuminates a little: http://pookzilla.net/wp/2005/12/context-capability-and-perspective-2/
(In reply to comment #6) > Kim has a blog entry which illuminates a little: > http://pookzilla.net/wp/2005/12/context-capability-and-perspective-2/ > I might have understood what this means. So we should all have an extension point org.eclipse.ui.activities, defined in a separate plugin, that we should add to a separate feature. So this bug means I need to add a new plugin and a new feature to my build ? How does this scale for projects that have complex builds (I'm looking at you, EMF) ?
We might want to be more clear that only projects that make UI contributions need capabilities. I think we have another problem here as well. EMF has a large number of features and many of them make UI contributions. This would seem to imply that each ought to have separate capabilities support relative to those specific contributions. But we sure don't intend to double the number of feature along with one extra plugin for each. I'm starting to rethink whether this is even a completely reasonable requirement. It's not difficult to determine what's being contributed and filters can be written externally with little effort. Examples are helpful but are strictly even necessary. This reminds me of http://ed-merks.blogspot.com/2008/06/rules-making-breaking-and-following.html and makes me want to remind the rule makers (and if that includes me, to remind myself) to consider the costs of the rules for the affected parties and also the implications of having to enforce them. All we need is for one key component not to comply and the train comes to and end. So perhaps we should consider more carefully which rules are actually worth terminating the train. EMF has capabilities in its example feature. I wonder if that counts as compliance?
To reiterate once again, we're expecting the absolute minimum this time around. To avoid the impact to release engineering, what if we defined each participant's capabilities within Galileo itself? The way the build works this year, I have a feature and branding plug-in that goes with the product definition for Galileo. I could easily add a capabilities plug-in and feature where we could consolidate all definitions and provide to the community for those interested in them until subsequent releases when we figure out the best approach to delivering them.
(In reply to comment #8) > We might want to be more clear that only projects that make UI contributions > need capabilities. Agreed, but name a project that does not have any UI? > EMF has capabilities in its example feature. I wonder if that counts as > compliance? Yes Ed, I think you are probably 97% there, you already provide an "EMF Capabilities Example Set". You just need to change the "example" name and give it some polish so we can reuse them. All we are asking for is a simple set of capabilities that you would recommend we put in a package that includes EMF. We will turn off your contributions by default, as novice users will not know what "EMF Development" is and we do not want a bunch of strange wizards showing up in File -> New. But when an advanced user wants to make use of EMF, they can turn on the "EMF Development" capability. Each project is in the best position to determine how their capabilities should be setup. This is where you come in Ed. Is there a need for a "Basic EMF Development" and a "Advanced EMF Development" capability required?
The XSD project only has a sample editor that no one consumes for real because WTP has the real one. So it's just framework. I think some of Christian's components are the same... Notice that already we're already talking about subjective things like do we need advanced and or basic, rather than just one switch? The answers to these will be relative to the final product, not just my decisions. My users don't need anything filtered out! I don't know who would need things partially filtered...
Fair enough Ed. When I download EMF-ALL, I want "EMF Development" to filter all of your UI contributions. Completely up to you if you want it more fine grained, it is your component and you are in the best position to guide us. Christian has examples with UI, when I download Christian-ALL, I at least want an "Christian-ALL Development" capabilities to filter all of his UI contributions as something to start with.
Anthony has suggested "We will turn off your contributions by default, as novice users will not know what "EMF Development" is..." Let's imagine a visit from the Ghost of Eclipse Yet To Come here... This requirement is met by all of the projects participating in Galileo in the most basic way possible. For each project, there is some number of activities (let's say 2 - beginner and advanced). Looking at http://wiki.eclipse.org/Galileo_Simultaneous_Release that seems to translate into a conservative estimate of 2 x 40 new activities. Now, activities don't work in a vacuum. They require breadcrumbs throughout the UI that allow users to trigger their enablement. The primary trigger mechanism happens to be the new wizard dialog. The contents of this dialog honour activity enablement by filtering from the category tree any item bound exclusivly to an 'off' activity. HOWEVER, we've intentionally allowed product teams a way around this restriction - they can specify that one (or many) of their wizards are 'primary.' These wizards exist as top level elements of this tree. Are component teams also expected to contribute a primary wizard as a means for users to first experience their project? If so, that means we'll have another 20 or so new wizards at the top of that tree. If not, then how are we expecting users to experience all that Galileo has to offer? Downstream products (IBM products) accomplish this by providing custom welcome experiences that help guide the user into the various pieces of functionality that their products offer. In Eclipse we don't have any such thing. We rely on a) the primary new wizards b) opening a perspective and c) the capability preference page. This page now, by the way, will have 80 or so new elements at best and that's only if we can manage to herd everyone into using a particular category structure. If each team also invents their own categories, that page becomes truly moribund. In effect, the experience will be that I download Galileo in all of it's glory. To do this, I've navigated some checkbox tree and picked a bunch of components that interest me. After downloading I fire it up and find out those things I've just checked off aren't actually visible. Not only are they not visible, I don't know WHY they aren't visible. If I go to the new wizards I see a flat list of wizards that seem interesting but without the context of their category I'm not sure what they are. If I do manage to find the preference page I'll end up with a hierarchy that looks a lot like the one I used to download Galileo in the first place. One similar enough that I might wonder "if I've checked this stuff off once, why am I checking it off again?" This is the point where I cry out "I fear you more than any spectre I have seen" and promise the ghost that I can change my ways. I wake up and flip a coin to the begger child on the street, instructing him to buy the biggest turkey he can find and deliver it to the doorstep of Ed Merks.
(In reply to comment #13) > Anthony has suggested "We will turn off your contributions by default, as > novice users will not know what "EMF Development" is..." Kim, I think we are on the same page. For Galileo packages, we leave everything on, but have the fallback of capabilities if users want to turn things off. For those building on Eclipse, we use those same capabilities to turn off those same capabilities by default if we want, but that is up to the product. The key here is a starting point ==> some capabilities.
Is it possible to see an example of how the second part of the requirement (placing activity definition in a separate plugin, presumably with a separate feature) is expected to work? In my naive guess: two downloads would be provided per logical feature. Using JDT as an example, say download "JDT menus hidden" and download "JDT menus visible". The only difference between those two features would be defaultEnablement clause for the JDT activities. If this is correct, then a better way would be to have a plugin with alternative *defaultEnablements* for activities, not with activity definitions as definitions will be the same for both cases. But anyway, consider the result: [feature] JDT with menus enabled [feature] JDT [plugin or feature] plugin with JDT activity enabed [feature] JDT with menus disabed [feature] JDT [plugin or feature] plugin with JDT activity disabled If this is correct, then for each UI feature we currently have we'll get two extra features plus two extra plugins. Hmm. It seems that a better way to solve the original problem (hiding unwanted menus) this would be: 1)Move existing activities into the existing domain bundles (say, org.eclispe.jdt or org.eclispe.jdt.ui for JDT). Create new activities as necessary in the domain bundles. It will be up to the domain to specify "default" default enablement. 2) Create a way to override default enablement of activities on the product level (or application level?) For Eclipse SDK this would go into org.eclipse.sdk, for an RCP application it would go with the RCP apps product or application definition. This way: - there is a clear answer as to who decides what's initially enabled; - there is no duplication of features and downloads From a more broad perspective, this underscores a need for multiple levels of customization: features provide default values, then application has a chance to override them with application-level default values. Interestingly, this same problem with UI contributions did rise before and last time resulted in Equinox transform bundles.
The requirement has nothing to do with the default enablement state of the capabilities. It simply requires having configurable categories so that users can disable them. The desire is to keep them separate since it's highly likely that folks assembling an actual end user distros will want to define the categories themselves and also decide for themselves what's enabled by default and what isn't. I.e., the capabilities are mostly intended as a well-thought-out example from the perspective of each provider/project rather than as something that's likely to yield a coherent set of categories across the board... EMF includes it's capabilities along with its examples as an example...
Ed, if that's correct, then implementing changes as specified in this request will require consumer to edit plugin.xml of the consumed bundle(s). What happens with: - Signing: editing plugin.xml will break signatures - Versioning - Conflicts: feature A want only menus A and B; feature B wants only menus B and C. - Compatibility across releases: activities use regular expression matching on non-API elements (IDs) that might change from version to version. The logical step then would be to create separate plugins with separate features with separate downloads - leading to 3x features and 2x plugins. The original request says that we have to place activities in separate plugins/features. How would that help? For instance, take org.eclipse.emf.activities. Can I specify that I'd like to use EMF without adding any UI elements? Without editing EMF code?
The problem is precisely that every end-point application is likely to want different ways of categorizing the capabilities as well as different choices for what's enabled by default. The idea is that you use the provided capabilities definitions as a guide or example to create your own, not to modify the ones being provided. EMF itself is decomposed into a large number of small features, so certainly there are subsets of EMF's features that would not include any UI contributions, e.g., the core EMF runtime is purely runtime.
Good, so it seems that there are three steps: a) who defines activities b) who enables activities c) how do I package activities > you use the provided capabilities definitions as a guide or example > to create your own, not to modify the ones being provided. Sorry, but I disagree with this. Here is a portion of EMF's activity definition (I am *not* picking on EMF; EMF is good; I am just using it as a example :-)): <extension point="org.eclipse.ui.activities"> <activityPatternBinding activityId="org.eclipse.EMF" pattern="org\.eclipse\.emf\.ecore\.editor/.*Ecore.*" /> <activityPatternBinding activityId="org.eclipse.EMF" pattern="org\.eclipse\.emf\.ecore\.editor/.*CreateDynamic.*" /> .... </extension> As a consumer of EMF, I don't want to know what IDs it uses internally to contribute UI elements. To me, a domain defines activities; then an application decides what set of activities it should enable by default. Next, how would it be packaged? Again, using EMF as an example, will the bundle org.eclipse.emf.activities be included in the EMF feature? If yes, then we'd get into conflicts with RCP developers. If no, then Galileo users would have no activities for EMF. That's why I am saying that we need to differentiate between people who define activities and people who determine what's enabled by default in their application. To me, a better answer would be: -> who defines activities: domain (EMF, JDT, etc.) -> who enables activities: 1) application/product (overrides domain); 2) domain -> how do I package activities: definitions: in the domain bundles (no need for a separate bundle) enablement: in the application/product customization (org.eclipse.sdk for Eclipse SDK)
It seems to me that all this discussion points quite clearly that the requirement is not likely to meet anyone's requirements and perhaps even that the platform's support for enablement verses categorization is insufficient. When we shipped EMF capabilities directly with EMF, IBM clients were up in arms immediately because they didn't like the way we categorized things. They had their own idea of what high level categories to provide and how to partition EMF's functionality into those categories. That's why we moved them to our examples and why the requirement is to keep them separate. So while you can want them directly included for good reasons, it's still highly unlikely to ever happen also for good reasons.
(In reply to comment #19) > -> who defines activities: domain (EMF, JDT, etc.) Correct, we are asking each domain to provide an example set of activities. > -> who enables activities: 1) application/product (overrides domain); 2) domain Correct, application/product enables activities. > -> how do I package activities: > definitions: in the domain bundles (no need for a separate bundle) > enablement: in the application/product customization (org.eclipse.sdk for > Eclipse SDK) > Correct, we have Eclipse packages (application/product) where we can make use of the domain activities to demonstrate they function correctly. So, why we are arguing about this, since this is exactly what we are asking for?
Arguing? Is someone arguing? :-P You'll note that Oleg was asking that capabilities be distributed directly with each UI-contributing feature so that clients would not have to worry about defining capabilities, yet the requirement is to make them completely separate. Generally this will imply capabilities being lumped into one big unit separate from the smaller feature units, i.e., there won't be a one-to-one correspondence between plugins defining UI contributions and plugins specifying capability controls for those contributions. Also note that he's asking for the "default" enablement of the capabilities to be determined/specified separately from the definition of the categories. I don't believe that's supported at all. I know it's possible to export and import preferences, so I imagine it ought to be possible to configure an installation with "default preference settings" but I wouldn't have a clue how one might go about doing that...
(In reply to comment #22) It is entirely possible to have activities defined in the corresponding *.ui plug-ins and then have a separate plug-in that controls their enablement and categorization. In fact, this would make the most sense to me, as a product branding plug-in should contain the categories and enablement defaults. In this case, we can use the Galileo branding plug-in for those not wanting to define a separate plug-in for this purpose.
(In reply to comment #23) > In > this case, we can use the Galileo branding plug-in for those not wanting to > define a separate plug-in for this purpose. Rich, where in CVS can we find the Galileo branding plug-in?
(In reply to comment #24) > Rich, where in CVS can we find the Galileo branding plug-in? It's still in its temporary location within Amalgam: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.amalgam/plugins/org.eclipse.galileo/?root=Modeling_Project
(In reply to comment #0) > 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. Can I ask for clarification on the original request? Is the intent that (1) product teams consuming the Eclipse IDE should be able to (completely) hide UI contributions, or (2) would the Planning Council like to see Capabilities that show up in the preference page so that end-users can enable and disable as they see fit? Both (1) and (2) are possible. (1) could be implemented through so-called expression-based activities that do not show up in the preferences, and (2) through "normal" activities. For details, see: http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/workbench_advext_activities.htm If the Planning Council would like to see (2), can the Council please come up with a common hierarchy of capabilities so that they make sense to end users? Without high-level input, we will run into problems similar to what we saw in the update site categories in the past.
(In reply to comment #26) While I'd like to believe we'd have adequate participation the Council to achieve 2), we concluded when coming up with requirement that it should remain as simple as each project providing the basic definitions for use by consumers wishing to organize and ship them within the context of their product. This is what motivated the bit about keeping them separate. If others on the PC want to give 2) a shot, speak up now.
I will do (2) for the modeling package. Given most projects will not complete capabilities until M6, that does not leave us a lot of time to accomplish (2). Product teams definitely need (2), which is how this request started....
(In reply to comment #28) > Product teams definitely need (2), which is how this request started.... Could you please explain this in more detail? The description of this bug says: "Each project will provide basic capability/activity definitions to allow for their UI contributions to be hidden.. [stuff deleted] .. by consumers in product development." (1) would do exactly this, and would not lead to a large number of incoherent entries in the Capabilities preference page.
For Ganymede: a) The platform SDK provided a "Development" top level capability that includes PDE and JDT development capabilities. b) EMF provided an "EMF Capabilities Example Set" top level capability that includes EMF, JET, XSD, etc. c) GMF provided no capabilities. For Galileo, at minimum, which covers (1) a) The platform SDK provides a "Development" top level capability that includes PDE and JDT development capabilities (no change) b) EMF provides an "EMF Development" top level capability that includes EMF, JET, XSD, etc. c) GMF provides an "GMF Development" top level capability that includes whatever the project thinks is appropriate. Agreed above covers (2) Now that we have a starting set of capabilities, we could take the above from the components and in the packages: a) Rename to "Eclipse Development" top level capability that includes PDE and JDT development capabilities. b) "EMF Development" under "Eclipse Development" c) "GMF Development" under "Eclipse Development". d) maybe align with the P2 update names, etc. I am saying I will do the above sweep for the modeling package if it turns out it is necessary.
(In reply to comment #30) > a) Rename to "Eclipse Development" top level capability that includes PDE and > JDT development capabilities. > b) "EMF Development" under "Eclipse Development" > c) "GMF Development" under "Eclipse Development". > d) maybe align with the P2 update names, etc. PDE makes sense under "Eclipse Development", but JDT is independent of Eclipse development and should be under just "Development". We really need to have this discussion, in detail, unless we are happy with random capabilities in random hierarchies in every Eclipse IDE-based product.
(In reply to comment #31) > We really need to have this discussion, in detail, unless we are happy with > random capabilities in random hierarchies in every Eclipse IDE-based product. Once again, the goal here is not to place these definitions within plug-ins that are required to be installed such that "every Eclipse IDE-based product" must be happy with them. If they are provided in separate bundles, the definitions that are best defined by each project can be categorized and enabled by anyone creating a product or package, which is the most appropriate use of capabilities, as I understand them. I do not believe an SDK branding plug-in is the appropriate place for these definitions to be placed, as indicated in comment #3.
(In reply to comment #28) > I will do (2) for the modeling package. Note that many Modeling project capabilities and categorizations have already been created for the Modeler and DSL Toolkit product-based downloads available from Amalgam.
After the reading the discussion on this bug I am still a bit lost how to proceed for the Mylyn project. We do not yet contribute capabilities and I am currently trying to determine the best place to put them. 1) Branding plug-in: If capabilities are specified in the branding plug-in every consumer (not just product developers) will get them when installing Mylyn. Since all Mylyn features include the branding plug-in it would be difficult for product developers who consume those features to specify different capabilities. 2) SDK feature: If product developers wanted to consume Mylyn's capabilities the SDK feature would force other potentially undesired plug-ins such as sources or documentation to get installed as well. This leaves creating an entirely separate Mylyn Capabilities plug-in and feature which adds some overhead and might be confusing to users of the Mylyn update site who are not familiar with the concept of capabilities. It would be helpful if projects that have already resolved this challenge could post details about their approach.
(In reply to comment #34) > It would be helpful if projects that have already resolved this challenge > could post details about their approach. Yes :-) The last time Oleg checked (a few days ago), this was the current state according to Bugzilla: "Already had it: 2 to 4 projects (BIRT, GMF (in "Amalgam"), SDK (?), EMF (in examples plugin?)) In progress: 2 projects (Mylyn and Datatools) No reaction / waiting / unsure what to do: 25 projects Seems that only Mylyn and Datatools actually did something about it; Datatools reported encountering some weird problems with capabilities."
What if we do the following: 1. Each project that doesn't already define capabilities (and perhaps some that do and want to do it better) create a new org.eclipse.<projectname>.ui.capabilities (or similiar) in which they define their activities (but NOT categories or default enablements). 2. You add this plug-in to CVS/SVN and include in a map file, but DO NOT include in your standard features. 3. I'll add this plug-in to the Galileo feature, along with categories and default enablements in the Galileo branding/product plug-in (where such definitions belong, imho). I'll add each map location to the build model, which will allow the build to pull from your CVS/SVN and use your tag. This way Galileo, EPP, Amalgam, or anyone else wanting to define a product-based definition can reuse each project's capabilities, yet categorize and enable as they see fit. Also, each of these included *.capabilities plug-ins will be available in the Galileo p2 repository for anyone to pull from when configuring their own products. I can follow this approach for GMF and include in Galileo to illustrate/document the approach, if everyone agrees it's worthwhile.
(In reply to comment #36) > > I can follow this approach for GMF and include in Galileo to > illustrate/document the approach, if everyone agrees it's worthwhile. > I can then take a stab with GEF. I can get James to do UML2 as well. Once we get a pattern of success, we should be able to build momentum and other projects adopting the approach.
See this wiki page for basic instructions on adding your capability definitions to Galileo: http://wiki.eclipse.org/Galileo_Capabilities
I added Subversive capability (org.eclipse.team.svn.ui.capabilities) but it caused in failing of Galileo builds (so it was removed). I used following syntax to add it to galileo.map: plugin@org.eclipse.team.svn.ui.capabilities=SVN,trunk,http://dev.eclipse.org/svnroot/technology/org.eclipse.subversive,,trunk/org.eclipse.team.svn.ui.capabilities. All entries now in galileo.map are for CVS repositories and I can't find how to make configuration for SVN repository. Could you please tell how to make configuration for SVN repository in galileo.map file (maybe any references to relative resources)?
I have added capabilities for EMF. Sorry for the unconventional name (org.eclipse.emf.activities), but I wanted to reuse the example we already had, converting it into something less example-like and more useful. I'm not sure if individual projects are supposed to decide on their category bindings and default enablements, or if that's supposed to be up to Planning Council, but I did commit changes to org.eclipse.galileo/plugin.xml for that purpose. In particular, I left EMF's JET tools and our sample Schema editor disabled by default, since there are better alternatives in Galileo. If anyone wants to revisit any of my choices, I'm fine with that.
I have added a "Task Management" category for Mylyn which has three bindings (Task Management, Task-Focused Interface, WikiText) that are enabled by default. I couldn't find any documentation on the process for adding new categories. Please let me know if this requires approval or review of some sort.
(In reply to comment #40) > I have added capabilities for EMF. Sorry for the unconventional name > (org.eclipse.emf.activities), but I wanted to reuse the example we already had, > converting it into something less example-like and more useful. > > I'm not sure if individual projects are supposed to decide on their category > bindings and default enablements, or if that's supposed to be up to Planning > Council, but I did commit changes to org.eclipse.galileo/plugin.xml for that > purpose. In particular, I left EMF's JET tools and our sample Schema editor > disabled by default, since there are better alternatives in Galileo. If anyone > wants to revisit any of my choices, I'm fine with that. > Not sure if this is the right place to discuss this, but today I had a serious usability issue with capabilities. I downloaded the latest EMF bits from the interim update site into my brand-new Eclipse 3.5M7, only to find I still could not open .ecore files. Only after I tried older versions of EMF did I find out that the latest build (200904281800) uses capabilities, having most EMF features (like e.g. the Sample Ecore Editor) being turned off. IMO, this is a serious usability issue - I wasted quite some time to find out what was wrong. I guess this is not only an EMF problem, but holds true for most other projects. I suggest that when a user downloads a feature, that feature be activated. After all, the main reason for downloading a feature for me seems to be to use it ;-)
(In reply to comment #42) Peter, This is a unique problem to EMF, so this bug probably isn't the best place to discuss it. The reason for it is that our capabilities plug-in is doing double duty: (1) as the real Galileo capabilities plug-in and (2) as an EMF example. We had a previously existing capabilities example, which I just modified to use for Galileo. Unfortunately, the modifications make it, when running on its own without the org.eclipse.galileo plug-in, hide all the activities it defines with no obvious way to turn them on. I figured this wasn't so bad, since we've been telling people for years not to actually run the EMF examples in their Eclipse installation (and since they already do bad things like add useless artifacts to the generator). But, in retrospect, this was a very bad idea, as lots of people aren't following our advice and so they're getting hit by this very nasty surprise. If you want to open a new bug, I'll consider reverting the capabilities example to one that works properly on its own and adding the Galileo version separately.
I've submitted a corresponding bug for EMF : https://bugs.eclipse.org/bugs/show_bug.cgi?id=275418
Created attachment 146091 [details] Screenshot of the Modeling Tools download As a retrospective, I checked the end results by downloading several Galileo packages. PHP, C++, Pulsar (Mobile), "Java and Reporting" (Birt) did not have "Capabilities" page at all. After I added the page, it seems that they either add no capabilities beyond SDK (for instance, the C++ package), or add one single extra capability (like Pulsar and Reporting editions). On the other end of the spectrum is the Modeling edition, picture of its capabilities page I am attaching. To me, this is a perfect illustration of the concerns that Kim and Boris expressed in the comments on this bug.
THis is a routine mass closing of the previous release umbrella tracking bugs.
