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.
CDO/Net4j are run-time technologies. All generic user interfaces are considered as usage examples. Therefor I always pulled the "technical reasons" card. Nevertheless I'll put it on my nice-to-have list.
Not applicable for Teneo
The only UI in the following components is a "New Example Project" wizard in the SDK: Query Transaction Is that to be controlled by a Capability? If so, then I am no longer in a position to implement this. The Validation component has a preference page that should be subject to a Capability. Again, I am no longer in a position to implement this, so the Validation component will be late meeting this requirement.
EMF core currently has capabilities defined in an example plug-in (org.eclipse.emf.activities). Our examples are not actually delivered as part of Galileo, however. I wonder if this is sufficient to meet this requirement? We originally put this in an example because we weren't sure what to call our capabilities, and we didn't want them to start popping up in people's EMF-based products. Instead, we thought, it would be better to provide an example that people could use to define them as they see fit. If the idea is for all projects in Galileo to provide capabilities, themselves, then maybe we could coordinate amongst ourselves in the modeling project and all use the same category? This surely won't be an improvement to the UI if the user is faced with scores of new categories of capabilities. Does anyone know what other modeling projects are doing?
This is now done for EMF core. See bug 270528. Eike, Martin and Christian, If any UI from your component shows up in a full Galileo install, whether or not you call it an example, this requirement does apply to you. If you only have example UI that is *not* included in Galileo, then it doesn't. I'm happy to throw other people's pattern bindings under my activities (and/or add additional activities), making just a single plug-in for all EMF components. If you need this, let me know, and we'll coordinate it.
Hi Dave, Teneo only adds a submenu when you right-click an ecore file. I guess this also must be included.... What do you mean with pattern bindings? (I am afraid that this dummy-question exposes my total lack of knowledge here....) gr. Martin
Hi Martin, Take a look here: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org.eclipse.emf/examples/org.eclipse.emf.activities/plugin.xml?root=Modeling_Project&view=markup That's all that's required to define capabilities (and, of course, the strings defined in plugin.properties). It's all done by contributing to the org.eclipse.ui.activities extension point. Of the five types of elements that can be defined, only two appear here: activity - defines an activity (in the UI, these are exposed as some kind of sub-capabilities, which are seen only when you click "Advanced..." on the General > Capabilities preference page). activityPatternBinding - binds an activity to a regular expression. If any UI contribution has an ID that matches the pattern, then it is hidden or shown according to whether the activity to which it is bound is enabled. The other three (which I have included in the file, but commented out) are actually done in the Galileo plug-in: category - defines a category for related activities (in the UI, this is exposed as a capability right on the General > Capabilities preference page, but only if if it has any activities bound to it). categoryActivityBinding - binds an activity to a category. defaultEnablement - specifies that an activity should be enabled by default. So, if I added an activityPatternBinding, I could bind a pattern that matches your UI contributions to one of my EMF activities. Unfortunately I can't really add additional activities as I first suggested, since they would show up in the Capabilities preferences even if Teneo wasn't installed, and that would seem wrong. So, maybe it would be better if each component defined their own activities. Still, that does seem like a *lot* of plug-ins doing not very much.
Christian, What would you say to having your preference pages and example wizards covered by the existing EMF and EMF Examples capabilities, respectively? I can do this for you just by adding a few lines of XML to my existing plug-in. It seems reasonable enough to me.
I guess that we want own activities for CDO and Net4j. But I must also admit at this point in time that I'm totally unexperienced with this stuff. Vik, Can you investigate and take action?
(In reply to comment #8) > Christian, > > What would you say to having your preference pages and example wizards covered > by the existing EMF and EMF Examples capabilities, respectively? I can do this > for you just by adding a few lines of XML to my existing plug-in. It seems > reasonable enough to me. Hi, David, If I were a committer, I would say "yes, that is quite appropriate because these components were always intended to be closely knit." Of course, I am not, so I can't really answer. Probably best to leave the decision to Ed during the interregnum.
Christian, I guess that as a committer on EMF core, which is where my proposed change would go, I'd be free to make it. But, I'm happy to give a veto to Ed. Either way, thanks for your opinion, even if it doesn't carry the weight of a committer. ;-) Ed, What would you say to handling the capabilities for query, transaction and validation in EMF core's activities plug-in, as proposed in comment 8? Since I wouldn't be adding any activities (just binding more contributions to our existing ones), it wouldn't have any effect unless the QTV components were installed. It seems both a logical and expedient solution to me.
It sounds reasonable to me.
Great! This is now done for query, transaction and validation.
(In reply to comment #13) > Great! This is now done for query, transaction and validation. Thanks, Dave, for taking care of this!
You're most welcome.
Guys, we have UI contributions from both CDO and net4j projects. CDO provides example editors and views, a preferences page, example models wizards, and also a EMF genmodel wizard entry. Net4j does also contribute some views and examples. Since the question of including capabilities in the EMF core capabilities plugin has raised, I asked myself whether it would make sense to include CDO. It might make sense to include it, but I can't see a good reason to include Net4j. I see only maintenance disadvantages in this centralized approach: as soon as more UI is included in CDO/net4j, we'll have to sync filtering patterns with newly added UI contribution IDs (well, as long as patterns are no longer valid). I don't think you guys should be taking care of this burden :P What do you guys think? Should CDO/net4j create their own activities bundles? I've already created org.eclipse.emf.cdo.activities, should I bind our activities to galileo modeling category? Which are the critierias for default enablement, I guess true by default, right? Once done, should I raise bugzillas to request adding this bundle to the org.eclipse.galileo feature and adding an entry in a map in the org.eclipse.galileo.build/maps/galileo.map? Cheers, Víctor.
Guys, we are done with CDO and Net4j capabilities requirements. Comitted both org.eclipse.emf.cdo.ui.capabilities and org.eclipse.net4j.ui.capabilities to HEAD. CDO is under modeling category, and net4j is defined in the development category. So just let you know we are done with this :)
Great! Thanks Victor!
Still waiting for a final response from Teneo on this.
I have added an org.eclipse.emf.teneo.ui.capabilities plugin. So afaics Teneo now also adheres to this bugzilla. gr. Martin
And forgot to mention, will be in present in the next build... (so not in m7) gr. Martin
Looks like this is now done for all components.
(Oops, forgot to actually change the state.)
Closing all fixed releng bugs.
