Hi Didier
Integration of Kermeta seems like another good topic for an extended
EclipseCon. Perhaps you'd like to present something at the joint
Eclipse/OMG Technical Exchange on the preceding Sunday (official
Announcement as soon as the OMG URLs are defined.)
Regards
Ed Willink
On 10/01/2012 09:51, Didier vojtisek wrote:
Dear all
As a declared interested party of the MXF project, I was also
disappointed to see that nothing have moved in this project and
that I didn't had the opportunity to concretely contribute .
Anyway, if this goal of executable modeling and executable ecore
is still of interest for many (we still continue our development
on our implementation on the subject), our team would be happy to
renew our proposal to contribute and help to this initiative .
Our contribution could be trough our experience in developing
Kermeta. Shortly, Kermeta is a model oriented language and a
workbench that smoothly integrate with EMF to add executability to
metamodels thanks to static introduction. It has started in 2005
and the development is still active.
Maybe the evolution of the new MXF project could benefit from the
addition of some of Kermeta concepts that we have experimented and
validated ?
Regards
Didier Vojtisek
Le 10/01/2012 10:07, Philipp W. Kutter | Montages AG a écrit :
Dear Ed W.
Thanks for your note. The slides I sent you where about another
topic, and do not cover the topic we will contribute to MXF. We
will show that in March in the OMG/Eclipse symposium.
As well, I'd like to clarify, that MXF stands for Model
Execution Framework, not Model Transformation ;-) We do not
intend to contribute anything to model transformation, we use
QVTO for this at the moment.
I liked the MXF proposal details, and we will remain in synch
with the original proposal, and as well welcome, the original
implementation as one possible way to do a model execution
framework. We have a lot of respect from the work of the
original contributors, and I offered them our help at the
beginning - unfortunately never got a reply.
Unlike the original implementation, we will propose a leaner
implementation, that uses OCL to define actions, and that will
reduce actions to "one big step" without intermediate states:
this is XOCL.
Regards, Philipp
On 10.01.2012 09:12, Ed Willink wrote:
Hi
I'm looking forward to a presentation of XOCL, as part of the
joint Eclipse/OMG symposium just before EclipseCon, as a
chance to try to understand what XOCL is really about. I've
seen the "Montages AG - Business Modelling Practice and
Innovations" slides on which there is a nice two dimensional
editor for model instances, but beyond that it was not clear
to me what was new in comparison to what has happened in
parallel. Discussions on OCL Analysis have provided some
strong motivation for promoting the OCL Impact Analyzer from
examples in the Juno release, so that an independent
development can be replaced by a 'standard' one.
'Model Transformation Framework' is a wonderful term that can
mean whatever you want. When the original MXF was proposed I
was enthused, until I read the proposal detail and found that
it was nothing like what I was hoping for. I am sure that the
project name can be reused for a variety of purposes, but I
think it is unfair to burden any new project with the first
couple of years of misleading history.
In the meantime, as Ed Merks mentioned, Xcore/Xbase provides
an extended Ecore framework. With the advent of direct OCL 2
Java code generation for the dispatch table based OCL Virtual
Machine, the OCL VM forms the root of another model
transformation framework that can be extended to support QVT
and other approaches.
"From our side we will contribute one MXF framework called
XOCL, which is simply a set of standardized OCL annotations
for ECore models. This is, as Ed Merks mentions simply a usage
of existing stuff, not much new. "
This suggests that the new project is more like a library than
a tool. However the slides introduce both MCore and XOCL.
Unfortunately, as with many PPTs, it is difficult to grasp
quite what is going on without the presenter's words and pace.
MCore appears to be much more than a library; is it part of
the contribution?
The slides conclude with "MCore maps back to ECore + OCL
(XOCL) and can be considered as a simplification of modeling
with ECore and OCL". I would like to understand how this
compares with the OCLinEcore editor and its underlying use of
Delegates that were probably not available when the XOCL work
was started.
I welcome anything that adds to the capabilities of modeling
and OCL in particular, especially anything that adds manpower,
however I think the alignment with current projects needs to
be clarified and a clear scope and name for a new project
identified. Perhaps a meeting at EclipseCon may be helpful.
Regards
Ed Willink
On 10/01/2012 07:17, Ed Merks wrote:
Philipp,
I don't imagine what you're planning fits exactly the scope
that's been spelled out. 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...
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.
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.
Regards,
Ed
On 10/01/2012 6:50 AM, Philipp W. Kutter | Montages AG
wrote:
Dear Wayne.
Thanks for the clear directions, we will follow them.
I will start by discussing with prospective Architecture
Council mentors, for the topic at hand and then follow
their advice.
Where is the list of the Architecture Council members, and
which projects they already mentor?
Regards, Philipp
On 09.01.2012 20:15, Wayne Beaton wrote:
It seems that by not speaking, the project has spoken.
Or something to that effect.
Now it's in the Modeling PMC's hands. With their
unanimous consent, we can change the project lead and
committers. The easiest thing to do is to replace the
project lead and have the new lead retire the existing
committers and nominate the replacement committers via
the portal.
The Modeling PMC has to have a transparent discussion
about this. This discussion--which can be initiated by
anyone (either a member of the PMC, or somebody like
Philipp)--should include a few words stating that the
project team has become unresponsive and that another
party has stepped forward to take the helm. The
discussion should include some indication of confidence
that the new project team is ready for the
responsibility in terms of understanding the EDP,
working in open source, etc. followed by a minimum of
three +1s and no -1s from the PMC.
My records show that the project is in incubation, but
has no mentors assigned. As part of this reassignment,
I'd like to see at least one Architecture Council mentor
identified for the project.
Thanks,
Wayne
On 01/05/2012 11:44 AM, Philipp W. Kutter | Montages AG
wrote:
Agree 100%
As you wrote on 26.4. that you will check with them
the status, I assumed, that the fact that the project
is unresponsive is already here.
How long do we want to wait?
mxf-dev@xxxxxxxxxxx
should reach the original people, no? Hello: anyone
out there???
Regards, Philipp
On 05.01.2012 15:58, Wayne Beaton wrote:
How does the existing project team feel
about this?
The easiest way to proceed is for the existing
project team to accept your XOCL contribution, move
it into the IP process, and initiate committer
elections for the new developers (citing the
contribution as the required demonstration of
merit). Once on board, you can nominate and elect a
new project lead. That lead can retire the inactive
committers. The existing project lead can retire by
sending me a note.
That's the ideal.
If the project team is unresponsive, the Modeling
PMC can--after transparent discussion and unanimous
consent--decide to replace the project lead and
committers.
Make sense?
Wayne
On 01/05/2012 09:03 AM, Philipp W. Kutter | Montages
AG wrote:
Dear Wayne.
I have not seen anything since April now. I assume
thus that the project will be either closed, or
should be taken over from another party.
In the meantime we increased activities on our own
model execution framework, and we definitively
would like to take over the project. I cc'd their
mail list to see any reaction from the original
people.
The scope of the project needs not be changed, as
they positioned it as an open project, allowing to
welcome all MXF, not only the original proposed
one. Thus we will be open for the original
contributions, and others coming from the TopcaseD
area (see discussion on mail list).
In additon to the original scope, we will much
more be focused on project collaboration with
other Modeling projects, mainly those implementing
OMG standards, such as ECore, OCL, QVTO, Acceleo,
and DI from TopcaseD. Here the points we will
bring to the scene:
- ECore will be the basis for all metamodels, such
that other modeling projects for persistence (such
as CDO) and different ways to express syntax
(visual, textual, tree/table) can be added easily
- Reuse of _expression_ languages of other projects
(OCL, imperative extension of OCL from QVTO, and
newer ones like XBase)
We especially intend to use the project to make
sure that topics such as dynamic/static binding of
operation calls, overriding/overloading, multiple
inheritance are solved the same way as in
ECore/Java. (we filed Bugzillas for this topic in
the OCL project, which where already partially
fixed)
From our side we will contribute one MXF framework
called XOCL, which is simply a set of standardized
OCL annotations for ECore models. This is, as Ed
Merks mentions simply a usage of existing stuff,
not much new.
Michael Golubev will bring the knowledge to the
scene, how to do the builds and will help me to
follow all the Eclipse processes. He is the
component lead for GMF Tooling and UML2 Tools.
Thus: there needs nothing to be added to the
original plan.
Please let us know how to proceed.
Regards,
Philipp
On 26.04.2011 14:54, Wayne Beaton wrote:
Hi Philipp./
The project appears to be dead on arrival :-)
I will check with the PMC and project founders
to see what their plans
are. Hopefully you'll see some activity from the
project.
Wayne
On 04/26/2011 05:16 AM, Philipp W. Kutter wrote:
Dear Anne.
Has there been any news since 7.4.2009?
I have neither seen the Eclipse page, nor the
initial code contribution.
Any input welcome. I will as well try to
contact the founders of the
project as soon as I find time.
Regards,
Philipp
Am 07.04.2009 18:47, schrieb Anne Jacko:
Hello all,
Since there has *not* been a request from a
member of the Eclipse
community to hold this review on a
conference call, there will be no
Review Call tomorrow (April 8, 2009).
The EMO has declared this review to be
successful based on the review
docuware and on community feedback.
Congratulations to the MXF team on
their successful review.
Please contact emo@xxxxxxxxxxx
with any questions. Thanks.
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
--
Didier Vojtisek
Research Engineer
|
Breathe life into your metamodels
www.kermeta.org |
CENTRE DE RECHERCHE / RENNES -
BRETAGNE ATLANTIQUE
Campus de Beaulieu F-35042 Rennes cedex France
Phone : +33 (0)2 99 84 75 07 Fax : +33(0)2 99 84
71 71
www.inria.fr
|
|
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4733 - Release Date: 01/09/12
|
