Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migr

[Richard Gronback <richard.gronback@xxxxxxxxxxx>]

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
>