Sven,
See inserts below...
Thanks,
Rich
On 8/25/08 10:57 AM, "Sven Efftinge" <sven@xxxxxxxxxxx> wrote:
Rich,
sorry I originally wanted to write this mail before you propose the
component. Hopefully you still welcome a discussion on this.
It was my interpretation that we ended the call in agreement that a new
component in M2T was the way to go. For those not interested in what
is a
Modeling project conversation to follow, feel free to ignore the rest of
this reply.
As said during the PMC call, I really understand your need to remove
the "Xpand variant" from GMF and I also know that it has been promised
by committers of the M2T/Xpand component to provide a working Xpand
within the ganymede release.
Right, and since there has not been a published build from Xpand since
January, very little activity in CVS, the newsgroup, and in the mailing
list, I'm inclined to request a Termination Review for this component.
It's really a painful situation having
this dialect within GMF, especially when people use the real Xpand and
the modified version shipped with GMF at once. This is the case for
all GMF users doing code generation with oAW (and AFAIK there are a
lot). Unfortunately having an "official" Xpand dialect in addition
would further worsen the situation.
I'd characterize it as unfortunate, more so than painful. Let's not
forget
that the original variation was produced in order to leverage LPG, as
Xpand
was using a non-EPL friendly ANTLR version which took a very long
time to
resolve in the original. IOW, waiting a year for the ANTLR update
and now a
year for GMF changes to be incorporated into the "real" Xpand, with a
follow
up of "please wait for us to re-implement it all on a new (unproven)
underlying foundation" does not seem too appealing.
So, I see and understand your need for a solution, but I doubt that
it's a good idea to come up with yet another template language.
We already have three languages in M2T:
- JET (the orginal solution from EMF)
- MTL (the implementation of the OMG standard, which uses OCL and Op-
QVT)
- Xpand (a practice proven solution)
This argument can be made for other Eclipse projects with overlap, and
certainly within Modeling itself (e.g. M2M: ATL and QVT).
Realistically,
the 3 M2T solutions we have will never merge into one, and as long as
all
have vibrant communities, why does it matter if there are 3? This was a
challenge we realized when creating Modeling, as it was a unification of
many separate projects, each with teams/communities that were
unlikely to
give up their identity.
Besides that you need a template language now, because you want to get
rid of the "Xpand variant" (I fully understand that), I don't see how
an "Xpand OCL" would add any value. I think there are already
solutions for everybody: If you like standards and want to be conform
go for MTL, if you like pragmatic solutions go for Xpand, if you like
Xpath go and use JET.
We think it adds value as it eliminates an entire _expression_ and
transformation language (Xtend, which from your previous argument
should not
exist in the presence of M2M QVT and ATL). By using MDT OCL and M2M
QVTO,
we are promoting reuse from other Modeling projects, which seems
better than
continuing to develop and maintain Xtend and the _expression_ language
currently used in Xpand. As I understand it, the only reason OCL wasn't
used in the first place was because there was no MDT OCL at the time.
The way I see it, we're providing a nice migration for Xpand and
improving
its capabilities. From the original, we now add OCL and QVTO support,
thereby allowing users to know fewer languages, and not have to deal
with
the minor differences that currently exist. From here, I'd expect
that a
future Xpand based on Xtext could also use OCL/QVTO in its
implementation,
providing the next major version of the project.
So, Xpand/Xtend -> Xpand/OCL/QVTO -> Xpand/OCL/QVTO based on Xtext
Or, are you saying you reject the inclusions of standards in Xpand
and see
the two as mutually exclusive? I don't see the "if you like
standards, use
this..." argument as valid. Or if you like, we'll say "If you'd like
some
standards in your Xpand, use this one."
In case you want to migrate to the real Xpand language you can do so
by the end of this year.
Based on the past and given the complete lack of visibility into how
this
work is progressing, how can we be sure that we will really be able
to adopt
the new Xpand by the end of this year? I don't have a "warm and fuzzy"
about it, to be honest.
As the current GMF generator is already implemented in Xpand it
shouldn't be too hard to migrate and to have everything working and
tested for the galileo release.
Another argument would be, if we have a migration utility that can
ease the
conversion of existing Xpand templates ("original" and GMF), why not use
this as a path toward making Xpand more "standard"? Have you queried
your
clients to see if OCL would be an acceptable alternative? I suspect
as OCL
is used so pervasively in modeling technologies, it would be a welcomed
change.
Note, that there is a huge user base (we've up to 70 messages a day in
our forums) and all these users will be able to use, understand and
enhance the generator shipped with GMF.
By "our forums" which do you mean? The only ones we really should be
considering in this discussion are Eclipse forums. Again, as an Eclipse
project, we all need to openly and transparently develop and interact
with
the Eclipse community. If you mean oAW forums, that's an old
discussion we
thought had been concluded with the termination of the oAW component
within
GMT and the migration of several technologies, Xpand included, to other
Modeling projects. The health of an Eclipse project is measured by its
activity on Eclipse forums only, so you're only hurting your
project/component by continuing to use external forums.
Note that TMF/Xtext's (textual equivalent to GMF) generator is also
implemented in Xpand, and we are working on combination and
integration of GMF and Xtext editors. It will be helpful if there are
not two many different technologies for the same purposes.
And I'm sure the ATL/TCS folks would have their own opinion and
similar set
of technologies.
All in all I'ld like to see GMF migrating to M2T/Xpand. We can of
course talk about opening up Xpand so that it would be possible to use
Operational-QVT functions like Xtend functions (that really would be a
good thing!).
Again, the past indicates that "opening up" is not something the
Xpand team
takes too seriously, or has not enough development bandwidth to properly
support. On the other hand, we've been using Xpand for years in GMF,
provided valuable input and the implementation to improve the
original, but
have been largely ignored. What would you do?
But it's not possible for us to just change the _expression_ language to
OCL, because this heavily breaks API contracts.
(Don't you also have API contracts in GMF? AFAIK the current modified
Xpand shipped with GMF uses the original _expression_ language. Doesn't
the OCL migration mean that all the templates of the users will be
broken?)
As was already stated, we will provide a migration utility. The
codebase
itself is within internal packages, so there are no API breakage
issues (we
know better than to expose as API a technology that for all intents and
purposes shouldn't be in GMF anyway). That said, we currently
support UML2
Tools and our commercial development efforts with the GMF variant, so we
clearly understand the implications of this move. In the long run,
how can
you argue it would be better to develop and maintain a "proprietary"
Xtend
and _expression_ language rather than leverage suitable and quite similar
standard-based implementations available within Modeling?
Hopefully you don't get me wrong. I definitely see your point but
coming up with an "Xpand OCL" component IMHO will definitely hurt the
acceptance of Xpand *and GMF*. And will make it more difficult to
understand and combine the different solutions.
Especially in EMP we should work on reuse and consolidation rather
than on inventing new things when there are already solutions. That
clearly means making compromises, but I'm pretty sure they are worth
it.
Your "reuse and consolidation" argument doesn't make any sense to me,
actually. By leveraging OCL and QVTO, we're certainly moving toward
this
goal in GMF's Xpand and would like to make it more readily available
to the
rest of the community by moving to M2T. If you'd like, we can rename it
entirely, so as to avoid further confusion.
I'll respectfully disagree that using OCL within the context of Xpand
will
hurt GMF.
regards,
Sven
On Aug 25, 2008, at 3:55 PM, Richard Gronback wrote:
Hello,
As discussed on the last PMC call [1], we'd like to finally get the
Xpand
variant out of GMF and into M2T where it belongs. Given the current
migration of the current Xpand to an Xtext-based foundation, and
given the
desire to continue using Xtend and underlying _expression_ language by
the
current Xpand team, we'd like to create a new 'Xpand OCL' component
in M2T.
This version of Xpand will use OCL and QVTO for the query/_expression_
language, and include the enhancements made to Xpand for GMF's needs
[2],
but which were never fully implemented in the original Xpand. Also
provided
will be a migration utility that converts the use of Xtend to OCL/
QVTO. The
initial committers for this component will be Artem Tikhomirov
(lead) and
Alexander Shatalin (both GMF committers already).
Copying the GMF and M2T dev mailing lists to get approval for code
migration.
Copying the Modeling PMC to get PMC approval (obviously, my vote is
+1).
Copying the EMO to serve as indication that the obligatory community
announcement needs to be made for this new component. Actually, as
it's not
really 'new' but just relocating, is this necessary? It can't hurt, I
suppose.
Copying the IP team for confirmation to get clarification on what
moving
code from one project to another will entail, from an IP perspective.
Anything? A CQ for tracking purposes? Maybe we could use a cartoon
for
moving code between projects? ;)
Copying Bjorn as the "master of process" to help identify any
complications
the newly approved development process changes may present in this
move. I
didn't see anything specifically on this under /dev_process, but
suppose
this topic could be the first under the "I am a PMC Member..." on [3].
Thanks,
Rich
[1] http://wiki.eclipse.org/Modeling_PMC_Meeting%2C_2008-08-19
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=202813
[3] http://www.eclipse.org/projects/dev_process/index.php
_______________________________________________
m2t-dev mailing list
m2t-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2t-dev
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
