Adolfo,
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...
Cheers,
Ed
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
https://bugs.eclipse.org/bugs/show_bug.cgi?id=299344).
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.
Cheers,
Adolfo.
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
|
