[ui] capabilities plugin makes Interactive OCL Console unuseable

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 304398 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Mar 02, 2010 13:52 EDT | | Modified | May 27, 2011 02:54 EDT | | Version | 3.0.0 | | Reporter | Ed Willink |

Description

The ui capabilities plugin provides the ability to disable UI contributions but does not provide the ability to enable them in the GUI.

Therefore anyone running up Eclipse with the capabilitites plugin finds the OCL Console unseable.

---

I have fixes/a rewrite pending as part of the OCL Editor contribution.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Mar 09, 2010 05:55

Ed,

The capabilities has been a long history.

The capabilities should have been introduced by every Galileo participating project -> http://wiki.eclipse.org/Galileo_Capabilities MDT/OCL didn't arrive in time due to committer's team transition.

To do this, every project had to provide a capabilities plugin which defined the capabilitie's "activity" and the galileo branding plugin should describe a common capabilities's "category" (Modeling, for MDT-OCL) and a "categoryActivityBinding", so that's the reason why the ocl capabilitie's plugin in its own is not showed in Preferences -> General -> Capabilities ¿?

The https://bugs.eclipse.org/bugs/show_bug.cgi?id=299344 bug explains that in Helios, the capabilities organization (categories, and bindings) will not be included in Helios product. That could be the reason why you can't enable the OCL UI capabilities.

The bug also relates the need of doing one of the following actions:

1. Include in our builds the capabilities bundle (with a proper category and categoryActivityBinding, at OCL/MDT/Modeling level)
2. Provide adequate documentation for what a package or product builder needs to know about our project capabilities.

I tried to get some consensus in a Modeling PMC meeting, http://wiki.eclipse.org/Modeling_PMC_Meeting%2C_2010-01-19 with no (enough) luck.\ In the las PMC meeting was not discussed neither. So, I guess we could accept the "Documenting it seems best..." as a suggestion to do 2.

About this bug, I'm not what your fixes are related to. Maybe including that categories and bindings ?. I don't know what to do with this bug, since it seems that capabilities bundle is not inccorrect at all. Maybe removing the capabilities bundle from the PSF should suffice.

Comments ?

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Mar 09, 2010 12:05

The attachment to Bug 289761 has a revised capabilities plugin based on the EMF one.

My understanding of the new policy is that we should now provide:

An 'activities' plugin defining the capabilities. Third parties can then incorporate these in their own categories.

and could provide:

A default 'categories' plugin ensuring that the capabilities are controllable.

The PSF should have both or neither of 'activities' and 'categories'.

Currently with just 'activities' the OCL Interpreter is mysteriously dead until the 'activities' plugin is deactivated.

I favour keeping the main PSF (the one on the project page) as small as possible, therefore the additional plugins go in some extra PSF.

[eclipse-ocl-bot]

By Ed Willink on Mar 11, 2010 02:41

Created attachment 161710 (attachment deleted)\ Distinct Activities and Categories

Attached replacement for org.eclipse.ocl.capabilities comprises

Activity declarations and bindings in org.eclipse.ocl.capabilities.activities

Activity categories and default enablement in org.eclipse.ocl.capabilities.categories

Therefore

case 1: Neither is used => facilities are always enabled

• simple PSF fetch

case 2: Both are used => facilities are enabled but may be disabled

• comprehensive PSF fetch
• standard build

case 3: Just activities is used => facilities depend on additional categories

• third party definition of capabilities

[The definitions are a little broad accommodating emf.ocl and ocl interpreter and anticipating the Editor and Model Registry]

Please:

a) +1 to replace the old plugin by the two new ones

b) +1 to change the default build to use both new ones

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Mar 11, 2010 05:25

Ed,

It's clear that you have decided to directly adopt action 1 (make MDT/OCL provide capabilities bundles instead of documenting how to do the said capabilities provision). I'm not sure if I explained well when I said that I tried to get a consensus about what should EVERY modeling project do and we got a "Documenting it seems best...".

Let me say that I feel happy providing OCL capabilities, however if we (I) tried to get a common decision for all modeling projects, which could even drive how the different activities are organized, I think we should align with this decision . If "We didn't discuss this either. Documenting it seems best..." is not sufficient clear statement to take an action, let's clarify what we should do before taking a decision for MDT/OCL.

I'll raise the question against the MDT-DEV list to see what we should do regarding capabilities, emphasizing that we tend to provide our capabilities plugin.

On the other hand, patch comments:

• If we are not coordinating our activities with a common category at MDT or Modeling project, we could define activities, the category and activityCategoriesBinding in a unique plugin. I think it's not necessary providing different plugins.
• From my point of view, I don't think it's necessary defining different activities. If you are interested in using OCL, you will want to see all OCL-related UI, if you are not interested in it you will disable all the OCL-realted UI . I'd only define a unique activity (OCL Development) with different patternBindings.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Mar 11, 2010 05:46

BTW,

I have checked that no Modeling project is providing their capabilities in Helios M5. In any case I think that the capabilities are useful and it's interesting that the projects provide them. Since EMF (core) is probably a required project for every Modeling project I'll propose the following capabilities organization:

Modeling - Category (defined by EMF core).\ UML Development - Activity (and Modeling-binding defined by UML).\ OCL Development - Activity (and Modeling-binding defined by OCL).\ EMF Development - Category (and Modeling-binding defined by EMF Core).\ Core - Activity (and EMF Development-binding defined by EMF Core).\ CDO - Activity (and EMF Development-binding defined by CDO).

Ideally UML and OCL could be organized in a MDT Category. However there is no a common o core project in MDT on which OCL and UML could depend on.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Mar 11, 2010 06:21

Adolfo:

A top Modeling level is certainly a good/essential idea.

However, you need to be much clearer about what you mean. I'm not sure where in:

Modeling - Category (defined by EMF core).

the UI text finishes and the commentary starts.

You need to present an approach that scales well to accommodate Acceleo, Modisco, ATL, ... (Hide the sometimes accidental EMF/MDT/M2M/GMT parent).

You need to explain how you cover the two major use cases:

a) standard deployment with default enabled capabilities\ b) custom deployment

[I handled a) by using both .activities and .categories, and b) by using just .activities with a custom rewrite of .categories.]

Since someone somewhere is going to have to write the relevant files, you would do well to provide prototypes that demonstrated spelling conventions for ids so that your prototype can be loaded and the visual effect assessed, discussed and compromised. Get the visuals right first, then the implementation subresponsibilities can be sorted out.

Does the three level hierarchy really work?

Moderately fine grained activities are useful. Certainly the Model Registry and Editor are distinct. Note that capabilities define what clutters up menus, not what is useable programmatically, so users may wish to prune menus selectively.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Mar 11, 2010 06:57

(In reply to comment #6)

Adolfo:

A top Modeling level is certainly a good/essential idea.

However, you need to be much clearer about what you mean. I'm not sure where in:

Modeling - Category (defined by EMF core).

the UI text finishes and the commentary starts.

You need to present an approach that scales well to accommodate Acceleo, Modisco, ATL, ... (Hide the sometimes accidental EMF/MDT/M2M/GMT parent).

I have a ready-to-send email for MDT-DEV list, I have rewritten the example, and think it clearly defines a mechanisms to plug project's activities in the desired \ categories. Continue the discussion there.

You need to explain how you cover the two major use cases:

a) standard deployment with default enabled capabilities b) custom deployment

[I handled a) by using both .activities and .categories, and b) by using just .activities with a custom rewrite of .categories.]

Since someone somewhere is going to have to write the relevant files, you would do well to provide prototypes that demonstrated spelling conventions for ids so that your prototype can be loaded and the visual effect assessed, discussed and compromised. Get the visuals right first, then the implementation subresponsibilities can be sorted out.

Does the three level hierarchy really work?

Moderately fine grained activities are useful. Certainly the Model Registry and Editor are distinct. Note that capabilities define what clutters up menus, not what is useable programmatically, so users may wish to prune menus selectively.

From my point of view it's uselessly useful. If I'm an OCL user I would like to have available all the OCL-related UI(Actually, I don't need to know which are all the UI components, regardless they are completely distinct or thery are not). Do you imagine that JDT doing a similar fine grained activities to all their UI components? OMG..... Let's make the things easy for the final user....

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Apr 12, 2010 10:24

Hi Ed,

In the modeling-pmc news list, Ed Merks concluded that capabilities won't be organized in Helios for the Modeling EPP.\ In the ocl-dev news list, you discourage working on this due to fact that e4 won't deal with capabilities.

In order to resolve this bug, I've decided to simply provide an OCL-Category, a categoryActivityBinding for the current OCL-Activity and a defaultEnablement for it, so that in case you (or somebody) has the non-shipped capabilities plugin into your workspace (from the CVS), you are able to properly deal with the OCL examples.

We will see in the next release what finally happens with the capabilities plugin.

The fixing patch comes now. I'm also starting the documentation about how third party packages should configure their own capabilities.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Apr 12, 2010 10:29

Created attachment 164563 Fixing patch

Fixing patch

:notepad_spiral: ocl304398_Capabilities.txt

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Apr 12, 2010 11:30

I've included the required documentation into the "New and noteworthy" page:

http://wiki.eclipse.org/MDT/OCL/New_and_Noteworthy/Helios#MDT-OCL_3.0.0_Capabilities

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Apr 19, 2010 05:31

Committed to Head.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:54

Closing