Ed,
I agree with your questions/concerns. I also have some doubts since I
don't have enough skills as a releng has. However, I guess that
adopting a similar approach as David described in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=299344#c0 for the wtp
project, could guide our modeling package and their
projects/components. I'll try to give some answers to some questions.
See in-lined comments
El 12/03/2010 13:59, Ed Merks escribió:
Adolfo,
Yes, the point is for capabilities to be in separate features and
bundles so they are easily excluded or included at the client's
discretion. It would certainly be very good if the Amalgamation
package provides a good set of capabilities and categories for
organizing them. Immediately the issue will come up whether we should
be organizing the categories to reflect project boundaries or around
functionality itself. E.g., does CDO Development mean anything or
should we be talking about Repository Development?
Agree, I usually think in terms of projects, when a better final
user-oriented message could be used. When a word such CDO is meaningful
to me, it could mean nothing to the final user.
Also the
question
of are they in the SDK zip needs an answer?
As David commented in the bug, the capabalities wouldn't be distributed
in the zip files.
At least
with p2 it's
easier to manage installing them optionally that way. I just don't
personally have the time or skills to deal with how this impacts the
builds and the packaging of the build result. If folks care to
volunteer to produce the bundles and features they want to see in the
core, and someone can help deal with the build impacts, then I'd
certainly be willing to pitch in.
Although the comments in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=299344#c0, which relate
to how WTP includes its capabilities, seem easy to adopt, I'm not sure
I should do it by myself. We would require some releng help to do it. I
could work on the capabilities bundle itself, to make this progress.
Another
problem that bothers me is
how many more such bundles/features do we end up with? EMF consists of
a very large number of fine grained features so that folks can consume
only the parts they need. As such, will we need many additional
fine-grained capability features and bundles to reflect that
granularity? E.g., it doesn't make sense for there to be an Ecore
development category if the GenModel and Ecore editor features
themselves aren't included.
Technically, I believe that capabilities enablement/disablement
mechanisms help here to avoid creating as many capabilities features as
many fine-grained features a project/component has. Although we could
take both approaches (A unique activity which binds to all UI-related
contributions of a project or, in the other case, several capabilities
bundles/features), I think it's an error creating a lot of fine-grained
features for capabilities, so that in case that an "Ecore Development"
category (we could also discuss on that ;P) doesn't fit, I guess we
will need to find a better name for it.
Cheers,
Adolfo.
Cheers,
Ed
Adolfo Sánchez-Barbudo Herrera wrote:
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
_______________________________________________
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
|
