Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Re: [modeling-pmc] Capabilities


The problem with providing capabilities is that the consumers of these various technologies often don't like the organizational choices provided by the suppliers. That's why capabilities were removed from the Helios Repo.  I'm just not sure how best to have then and yet also avoid distributing them by default...


Adolfo Sánchez-Barbudo Herrera wrote:
Hi Kenn,

I'm mailing to MDT-DEV (and modeling) to obtain again some guidelines about what MDT/OCL (and probably the remaining modeling projects) should do regarding capabilities (see In the PMC meeting in which this was discussed no conclusive decision was taken.

In principle, MDT/OCL wants to provide their bundles so that OCL-related UI may be disabled in the Preferences->General->Capabilities option. To do that, apart from the already made org.eclipse.ocl.capabilities bundle, we will also need to define a Category (Object Constrain Language) and an activityCategoryBinding to said category and include this plugin in our builds. However, we want to share this interest because we think we could get a proper organization for, not only MDT/OCL project but every Modeling project.

I'll expose some rules to stablish an organization policy for the modeling project's capabilities, which provides an easy way for every project to include their own capabilities and it's not intrusive for them. In order to provide a capabilities bundle every project should :
1. Depend on a modeling project which provides a Category:
2. Provide a capabilites bundles which define at least one Activity (with its defaultEnablement) and activtiyCategoryBinding which would bind its own Activity to the Category defined by the depending project.

Since EMF is a common project on which every modeling project depend, we could have the following organization example:

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 => Category (and Modeling-binding) defined by EMF Core.
             Ecore Development => Activity (and EMF Development-binding) defined by EMF Core.
             CDO Development => 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 or core project in MDT on which OCL and UML could depend on. This also occurs with other projects/subprojects paradigm such as M2M and ATL/QVTo. For theses cases they will need to plug their activities (or their own category) in the Modeling Category.

In order to make this happen for Helios, we would need at least that EMF Core provides a capabilities bundle which defined the "Modeling" category. Every modeling project could then plug their activities in that category and/or define new categories for other projects which depend on it. Since it's a non-intrusive design, every modeling project could contribute their capabilities for helios, or in future releases.


Adolfo Sánchez-Barbudo Herrera
C/Elías Ramos González, 4, ofc. 304
Tel.: +34 922 240231

_______________________________________________ modeling-pmc mailing list modeling-pmc@xxxxxxxxxxx

Back to the top