Hi Ed,
I could understand that third party consumers want a capabilities
organization different from that one established by us. However, why
does David give us the possibility of providing the capabilities
bundles ?. Actually, other projects are providing them and offering
some kind of organization. In my Helios M5 installation I can see some
capabilities for JDT, Team, etc.
In our Helios Eclipse Modeling Tools I would like to see as many as
capabilities as possible so that If I only wanted to work with Ecore
models and some QVTo transformations, I'd clean the remaining UI which
I'm not using. On the other hand, if third parties wanted to establish
their own capabilities organization in their RCPs, they could
selectively exclude the features which include our capabilities bundles
and provide their capabilitites by themself . Moreover, they would have
a prototype (acting as documentation) about how the capabilities bundle
should looks like.
BTW, I guess this should be a cross-modeling-projects decision, right
?. If a decision about not providing capabilities organization for
modeling projects is taken, we (MDT/OCL) should then change our mind
about providing these bundles and just documenting, shouldn't we ?
Cheers,
Adolfo.
El 11/03/2010 14:46, Ed Merks escribió:
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
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
|