Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)

Title: Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)
Stephane,

This is a topic that is as old as the Platform project, where similar issues have been dealt with for years.  What I need to know are the exact bugs that are contentious.  When I hear “10 bugs with patches have been ignored for over a year” and then I search and find 3 bugs that are relatively new, I shrug my shoulders and tend not to take the claim, and therefore the person making the claim, too seriously.  And I’m sure it’s the same on the other side of the discussion, where a few bugs are submitted, seemingly ignored, and then combined with the claims of others, leading to an impression that a project is not taking contributions seriously (which may be true, but which may also be false).  Human nature, I suppose.

Anyway,  there are many things to consider when accepting patches, as I’m sure you know.  When it comes to the runtime component, I defer to Anthony and team to evaluate each patch or feature, as there are a LOT of clients using the runtime.  Beyond the obvious need to maintain APIs, there are feature additions that may seem perfectly sensible to the contributor, but that don’t fit into the vision for the project from the perspective of those who built/maintain it.  The outline view discussion comes to mind.  What to do in cases like this?  In my opinion, the “owner” of the code wins, as they have the long-term stake in the code base.  

On the tooling side, we are very interested in providing extensibility through the generator.  We’re in the process now of incorporating some extensions done by UML2 Tools back into GMF.  As I’ve said many times before, this is the approach that is preferred and will contribute to the long-term success of GMF.  What I don’t see are too many that are interested in putting forth the extra effort to understand our code generation templates and contribute patches of this variety.  The nature of MDSD, I suppose.  The point here is that while it’s relatively easy to develop some new feature on top of the runtime or by modifying the generated code, what we really need are contributions that are at the level of template modification, or suggested improvements in the tooling models.  We’ve received a few contributions of this nature, but they are certainly rare.

So, there are bugs and there are features.  Bugs that have quality patches and unit tests applied are certainly to be taken seriously and dealt with quickly.  If they are not, then raise the issue in the newsgroup, mailing list, or even the PMC.  If it’s a feature and there is a degree of subjectivity involved, well then it’s up to the component owner to decide, ultimately.  If there are cases where it’s perhaps not that subjective, the issue is ignored, or there is some form of unsubstantiated refusal, then public escalation is appropriate.  I’d encourage more public attention to these matters, actually.

With respect to gaining Committer rights on the project, we stick to the Platform example of maintaining a high bar.  We need to see several quality patches and contributions from an individual before considering nomination to Committer status.  We see a lot of “drive by” patches and bugs, where it’s clear the person is implementing something using GMF, but will soon likely leave the space and isn’t therefore able/willing to invest the long-term commitment of contributing and maintaining code in the project.  Again, this is not only a GMF issue, but one that is found in most Eclipse projects.  Some projects lend themselves better to adding what I’d call “casual committers,” where part-time attention is sufficient.  In my opinion, GMF is not a project that falls into this category.

I hope this helps, and welcome further discussion on this topic.  Mostly, it’s my impression that contributors often don’t consider the full responsibility that comes with contribution (features, not bugs).  One way that the Platform tried to obtain more committers from outside (non-IBM) organizations was to offer a sort of intern program.  This seemed sensible to me, and would certainly work for GMF.  What it involved was a company to sponsor a full-time developer to work on the project under the guidance of one or more Committers.  This contributor would be expected to commit to a long-term stint on the project and gain Committer rights during the initial phase.  Certainly, the backing of a Strategic Developer would help the acceptance of such an approach.  Would Obeo be interested in something like this?

Best Regards,
Rich




On 8/27/08 2:53 AM, "Stéphane LACRAMPE" <stephane.lacrampe@xxxxxxx> wrote:

(adding the GMF mailing list in cc)
Rich,

Going back to the GMF patches, indeed Jonathan had the wrong numbers in mind, sorry for that.
Beyond that, I get the feedback from people from my teams that it takes quite long to have patches accepted under GMF, not necessarily the ones from Obeo. I do not want to be aggressive at all on that and we may have false impression.

But the thing is that we are working quite a lot with the GMF technology at Obeo for several customers as well as for Papyrus and Topcased, and because of this impression that it's difficult to get patches accepted, people tend to develop stuff to improve GMF without trying to raise a bug and submit a patch, which is definitely not a good habit.
What's your view on that ?

Anyway, because of all the work we are doing under GMF, I am trying to push people to get back on the right track and to provide more and more patches to GMF when it makes sense. We would then also be quite interested to get a GMF committer at some point, we could help to integrate patches as well as developing new features, do you think that it would be possible ?

Regards
Stephane LACRAMPE
Obeo CEO
Eclipse board member

Jonathan MUSSET a écrit :
Rich,
 
One of the Obeo guys sent me an email to say that 4 bugs were submitted and not 10 ;-)
For MTL and QVTO, You're right... It isn't available at the moment
But, We need a small part of QVTO (Functions)... It isn't a blocker point. We can already define queries.
We have made a lot of work since the beginning of the year... The documentations are coming soon.
MTL is not ready for your needs. Xpand is ready. Let's us create our community. The first version will be available in September.
I hope that your contribution will be integrated into Xpand, as an alternative of the navigation syntax...
 
Cheers,
 
Jonathan
 
 
Richard Gronback a écrit :

(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> <mailto: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> <mailto: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
    
 



_______________________________________________
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
  


_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc

Back to the top