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

Adolfo,

The PMC call ran overtime so we didn't fully discuss this issue. 
http://wiki.eclipse.org/Modeling_PMC_Meeting%2C_2010-03-16
I'm curious what happens if "the same category" is defined multiple times?  Do they get merged?  If so, then simply by agreeing to a convention (category names/IDs) projects could duplicate the definition of the category to ensure that regardless of what else is installed, their capabilities will be categorized. 

I'm just not in a good position, with so few active committers, so little understanding of the releng impact, and so many other things to do, to try to address this in EMF core for this release cycle. :-(

Regards,
Ed


Adolfo Sánchez-Barbudo Herrera wrote:
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.
--

Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

_______________________________________________ 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

--

Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

_______________________________________________ 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

--

Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

_______________________________________________ modeling-pmc mailing list modeling-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/modeling-pmc

GIF image

GIF image

GIF image