mxf-dev http://dev.eclipse.org/mhonarc/lists/mxf-dev/maillist.html mxf-dev en-us Thu, 22 Nov 2012 03:40:03 GMT Thu, 22 Nov 2012 03:40:03 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) mxf-dev http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/mxf-dev/maillist.html [mxf-dev] Commit rights for Michael Soden have been expired http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00033.html modeling.emft.mxf Committers, Ed Merks has expired the commit rights for Michael Soden (msoden). The reason for this change is: Project is terminated. modeling.emft.mxf Committers, Ed Merks has expired the commit rights for Michael Soden (msoden). The reason for this change is: Project is terminated. ]]> Thu, 22 Nov 2012 03:38:02 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00033.html emo@xxxxxxx (portal on behalf of emo) [mxf-dev] Commit rights for Markus Scheidgen have been expired http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00032.html modeling.emft.mxf Committers, Ed Merks has expired the commit rights for Markus Scheidgen (mscheidgen). The reason for this change is: Project is terminated. modeling.emft.mxf Committers, Ed Merks has expired the commit rights for Markus Scheidgen (mscheidgen). The reason for this change is: Project is terminated. ]]> Thu, 22 Nov 2012 03:38:02 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00032.html emo@xxxxxxx (portal on behalf of emo) [mxf-dev] Commit rights for Hajo Eichler have been expired http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00031.html modeling.emft.mxf Committers, Ed Merks has expired the commit rights for Hajo Eichler (heichler). The reason for this change is: Project is terminated. modeling.emft.mxf Committers, Ed Merks has expired the commit rights for Hajo Eichler (heichler). The reason for this change is: Project is terminated. ]]> Thu, 22 Nov 2012 03:38:02 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00031.html emo@xxxxxxx (portal on behalf of emo) [mxf-dev] Project meta data is out of date for modeling.emft.mxf http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00030.html Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is... Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ]]> Mon, 05 Nov 2012 05:00:21 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00030.html emo@xxxxxxx (portal on behalf of emo) [mxf-dev] Project meta data is out of date for modeling.emft.mxf http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00029.html Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is... Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ]]> Wed, 05 Sep 2012 04:00:20 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00029.html emo@xxxxxxx (portal on behalf of emo) [mxf-dev] [Follow up] Wish to take over MXF by Montages AG http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00028.html Actually, we like quite the original scope of MXF. I'll want to understand what concretely you have that fits this general scope verses what's specifically focused on OCL. I would be open to this, and actually, while I payed Alex Igdalov to work on XOCL f...
Dear Ed.
I want to follow up on the thread we interrupted on 10.01.2012 (see below).

And answer the questions you asked then, to comment whether it makes sense we take over the MXF Franework.

Based on your input we have evolved our work, and made all the Model Execution feature based on plain ECore feature
(EOperations and EAnnotations) and made it generic with respect to used _expression_ language to define those operations,
and used metamodels to define model-instances inside EAnnotations which are used as a further alternative.

Details are below.

Ed M.: I don't imagine what you're planning fits exactly the scope that's been spelled out.
PWK Actually, we like quite the original scope of MXF.
Ed M.:  I'll want to understand what concretely you have that fits this general scope verses what's specifically focused on OCL.

PWK:
The original "general" scope proposed a concrete action language to be used to add semantics to ECore models.

Our approach is to allow any action language or other kind of language to be used to add semantics.

The original proposal is a good example of one language that may be useful, the current and past proposals for using Action languages in UML are other useful ways, that could be translated from the UML metamodel to the ECore metamodel.

The commonality between these approaches is that they allow to define a certain order in which features of objects are updated, and operations are called.

While  it is trivial to model the order by derived features in a static way, the updates need to be specified.

Thus our own approach is to only give means how to define which objects are updates, and for these objects, which features are set to which new vvalues.

The way we do that is by defining one update by pointing to a feature, and specifying in two designated EOperations the objects to be updates, and the new values.

Then there are the usual ways to define these EOperations:
1 Java
2 OCL
3 Instances of other models, calling their operations
4 QVTO
5 XBase
-
We will do our own experiments with OCL, and a generalization of the original proposal, which was option 3 but with a fixed metamodel.

But the whole idea of EMF is that it does not matter.

Thus bottomline: we do exaclty what was the original scope, but we do it in a more generic way, and add plain OCL as an option, where this is enough.


Ed M. The new Xcore work is also about model execution (for Ecore), to some extent, but I'd rather keep that as part of the EMF project, not move it to a cross cutting project.
PWK: As described in the original MXF proposal, MXF is about supporting different ways to make ECore models executable. It is perfectly ok, that a specific way such as XCore is part of the EMF itself, but there should be a place for the other ways of making ECore executable.
Ed. M. Those places can be where the execution languages themselves are defined.

I agree. People who will use our framework and support a specific execution language like OCL and XBase can then put it to those projects.

Our work is about allowing to make plain ECore executable by supporting two ways:
- usage of instances of one executable model to define the semantics of a second one (as in the original proposal, but in our case not restricted to one fixed metamodel)
- specification of updates through EOperations, by declaring for which objects, which features change to which new values.

Please let me know whether this answers your concerns about generality.

All I would ask you for now is not to close that project until end of the year so we have time to discuss this further.

I will meet people in the US and UK in October, and would then be prepared to discuss more in detail with you in November.

Regards, Philipp


On 10.01.2012 10:48, Ed Merks wrote:
Philipp,

Comments below.

On 10/01/2012 10:22 AM, Philipp W. Kutter | Montages AG wrote:
Dear Ed M.
I don't imagine what you're planning fits exactly the scope that's been spelled out.
Actually, we like quite the original scope of MXF.
I'll want to understand what concretely you have that fits this general scope verses what's specifically focused on OCL.
Certainly things have evolved, as you know, since that scope for MXF was written, i.e., the introduction of delegates for operations, constraints, and derived features in EMF.  The combination of these things allow behavioral aspects to be defined directly in the Ecore model in an extensible way that supports languages like OCL.  I'd rather see things like XOCL be part of the OCL project than to revivew a stillborn cross cutting project.  Better the OCL project diversify...
I would be open to this, and actually, while I payed Alex Igdalov to work on XOCL for over a year, I told him to contribute as much to the OCL project, as the OCL project will welcome.

At the moment, we have good productive discussions with the OCL project, how to support the stable ECore targeted implementation without bringing in danger the new more OMG compliant Pivot implementation. Bringing any new aspects into this project, would be too much. OCL has lots of challenges ahead.
This divide between the pivot-model-based and the older more-specifically-targeted implementation concerns me.

The new Xcore work is also about model execution (for Ecore), to some extent, but I'd rather keep that as part of the EMF project, not move it to a cross cutting project.
As described in the original MXF proposal, MXF is about supporting different ways to make ECore models executable. It is perfectly ok, that a specific way such as XCore is part of the EMF itself, but there should be a place for the other ways of making ECore executable.
Those places can be where the execution languages themselves are defined.

I'm not sure how the other PMC members feel about this.  In general we have a large number of dead project that need cleaning up.  Personally, in the future, I'd rather see more life injected into projects that are currently alive.
I agree, this is a good way too. Exactly for that reason rather than sending the mail our right now to the PMC, I will discuss with a few people from the Architectural Council what makes sense.
They're likely to have zero insight into any of these issues, other than other members who are also PMC members.  In the end, the Modeling PMC has to agree to host the project.

I will certainly get back to you, and Ed W. and other people from the Eclipse and OMG communities as well, before getting into this again.

We may as well try to contribute it to an active project, which started to use OCL Annotations heavily: GMF Tooling. This would be in line with your proposal to support active projects, rather than starting new ones.
Yes.

Regards and thanks for the imput, Philipp




Montages AG

Philipp W. Kutter
CEO, Dr. sc. ETH
 Montages AG
Stampfenbachstr. 48
CH-8006 Zürich

tel:    +41 44 260 75 57
mob: +41 79 338 06 17
web: www.montages.com
]]> Sat, 14 Jul 2012 12:54:20 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00028.html kutter@xxxxxxx (Philipp W. Kutter | Montages AG) [mxf-dev] Project meta data is out of date for modeling.emft.mxf http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00027.html Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is... Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ]]> Thu, 05 Jul 2012 04:00:21 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00027.html emo@xxxxxxx (portal on behalf of emo) [mxf-dev] Project meta data is out of date for modeling.emft.mxf http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00026.html Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is... Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ]]> Tue, 05 Jun 2012 04:00:16 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00026.html emo@xxxxxxx (portal on behalf of emo) [mxf-dev] Project meta data is out of date for modeling.emft.mxf http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00025.html Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is... Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ]]> Sat, 05 May 2012 04:00:18 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00025.html emo@xxxxxxx (portal on behalf of emo) [mxf-dev] Project meta data is out of date for modeling.emft.mxf http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00024.html Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is... Michael, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no 'projecturl' pointing to the project home page * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ]]> Thu, 05 Apr 2012 04:00:18 GMT http://dev.eclipse.org/mhonarc/lists/mxf-dev/msg00024.html emo@xxxxxxx (portal on behalf of emo)