Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component propo

[Richard Gronback <richard.gronback@xxxxxxxxxxx>]

(narrowing list, as I'm sure the EMO and Bjorn have little interest in
this...)

Hi Jonathan,

I'm really interested to understand what you see as easier in
Xpand/Xtend/expression-language as compared to OCL + QVTO.  I get the
impression that few have looked at QVTO recently to see what it can offer
beyond the OCL in this context.  I don't believe MTL actually uses QVTO,
does it?  Either way, I feel the combination of Xpand with OCL/QVTO provides
the best overall M2T solution.  Hopefully, I'm not alone ;)  Maybe we just
need to let Alex & Artem finish their work and then provide a demonstration?

Also, I'd appreciate some help identifying the outstanding GMF patches you
mention.  I'm assuming "we" is Obeo?  In that case, I see 3 bugs: one with a
patch submitted in January; one with a patch re: code style submitted 2
weeks ago; the third patch was submitted on the 15th of this month.  Note
that I only searched for bugs submitted that included 'obeo' in the ID.

Thanks,
Rich


On 8/26/08 12:26 PM, "Jonathan MUSSET" <jonathan.musset@xxxxxxx> wrote:

> Rich, Sven,
> 
> I agree with Sven in a sens that I think it is not a good idea to create
> a new component in M2T.
> 
> At the moment, it is difficult to understand the difference between JET,
> Xpand, and MTL. But, we can argue :
> -JET : a Java/Xpath way, you don't need EMF, it is better if you don't
> have any model
> -XPand : easier to use because without OCL
> -MTL : the standard, a little bit more difficult because of OCL
> 
> I would not understand why there should be another Xpand OCL or another
> name when there is MTL component that is there to do the trick. The same
> was argued with us several times when we proposed to contribute the
> Acceleo code and its community to the M2T project : Acceleo was not
> enough "different" from what Xpand offers in M2T.
> FYI, we are working on MTL, and a version will be available in September
> with the target to provide a stable one for the next simultaneous
> release of Eclipse.
> 
> On the contrary, I hope that you'll find a way to work with the XPand
> guys to have your contribution integrated into Xpand.
> 
> Another subject is about the complexity of OCL. It is a real concern and
> this is one of the reasons why you find such a variety of modeling tools
> having their own navigation language (ATL, QVT, MTL, Xpand, Acceleo,
> JET...).
> I think we should discuss this with the OMG since some discussions have
> started between Eclipse and the OMG and we should carry on the work
> already made in MDT OCL to make OCL easier. It could be a good subject
> for the Eclipse summit as well.
> 
> Regards,
> Jonathan Musset
> MTL leader
> 
> PS : BTW, you argued about the fact that OAW did not considered your
> contributions, would it be possible for you to check at the different
> patches we submitted to the GMF team, there are about 10, some of them
> waiting for more than a year...
> 
> 
> Sven Efftinge a écrit :
>> Rich,
>> 
>> surely, I should have raised this discussion earlier.
>> 
>> Naming the component differently is a good idea and should avoid
>> confusion.
>> 
>> thanks,
>> Sven
>> 
>> P.S.: As most of the discussion is not directly related to this
>> component proposal but still interesting, I'll respond in more detail
>> in a separate mail, which I'll send to pmc mailing list only.
>> 
>> 
>> On Aug 25, 2008, at 7:08 PM, Richard Gronback wrote:
>> 
>>> 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
>> 
>> _______________________________________________
>> m2t-dev mailing list
>> m2t-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/m2t-dev
>> 
> 
> _______________________________________________
> m2t-dev mailing list
> m2t-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2t-dev