Hi all,
Since Anthony is away this week I'll be taking care of these patches
till he's back.
Jonathan, could you please specify which GMF version you'd like the
fixes to be comiitted for? (2.1.2 and 2.2 or 2.2 only is sufficient)
Now, Linda will commit the fix for 242283
I'll look into committing the rest.
215179 - you guys need to reevaluate this defect, since the related
code has changed significantly.
Cheers,
Alex
Inactive hide details for Richard Gronback
<richard.gronback@xxxxxxxxxxx>Richard Gronback
<richard.gronback@xxxxxxxxxxx>
*Richard Gronback <richard.gronback@xxxxxxxxxxx>*
Sent by: gmf-dev-bounces@xxxxxxxxxxx
27/08/2008 09:56 AM
Please respond to
"GMF Project developer discussions."
<gmf-dev@xxxxxxxxxxx>
To
<gmf-dev@xxxxxxxxxxx>
cc
PMC members mailing list <modeling-pmc@xxxxxxxxxxx>
Subject
Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component
proposal (code migration)
Thanks for this, Jonathan. It’s exactly what I’d expect and encourage
folks to do when it seems like their bugs aren’t getting the attention
they should.
As they are all runtime bugs, I’m certain Anthony will take a look.
Regarding 215179, if it’s a blocker, why not set the severity
accordingly? Severity is a user field, btw.
Thanks again,
Rich
On 8/27/08 9:42 AM, "Jonathan MUSSET" <_jonathan.musset@obeo.fr_> wrote:
Rich,
Sorry for the wrong number... They were about 10 in my mind
: perhaps 3 bugs + 4 patches == 10 with a french calculator
(Human shortcut)
I'm confused. I'll verify exactly my information the next
time ;-)
2 of them are from january and march...
But, I know the rules, and I can understand your reaction
I totally agree that there are many things to consider when
accepting patches but some of the following patches are
trivial
Here are more information :
patch for a bug opened by someone of IBM :
242283 : NullPointerException from
ViewUtil#getSourceConnectionsConnectingVisibleViews_
__https://bugs.eclipse.org/bugs/show_bug.cgi?id=242283_
patch :
_https://bugs.eclipse.org/bugs/attachment.cgi?id=110084_
bugs opened by someone of Obeo
243888 : [Code Style] some methods in
org.eclipse.gmf.runtime.diagram.ui.providers.internal.DefaultProvider
do not follow java code guidelines_
__https://bugs.eclipse.org/bugs/show_bug.cgi?id=243888_
A patch has been joined :
_https://bugs.eclipse.org/bugs/attachment.cgi?id=109789_
244297 : ScaledGraphics should allow one to set background
and foregroud patterns_
__https://bugs.eclipse.org/bugs/show_bug.cgi?id=244297_
A patch has been joined :
_https://bugs.eclipse.org/bugs/attachment.cgi?id=110091_
215179 : The way
DiagramGenerator#findConnectionsToPaint(...) gets the view
connections source will cause the image export to fail_
__https://bugs.eclipse.org/bugs/show_bug.cgi?id=215179_
A patch has been joined :
_https://bugs.eclipse.org/bugs/attachment.cgi?id=91333_
215179 is a trivial patch and it is a blocker point for us
244297 is very usefull for the SCA designer
Thanks,
Jonathan
Richard Gronback a écrit :
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@obeo.fr_> 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@obeo.fr_>
<_mailto:jonathan.musset@obeo.fr_>
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@efftinge.de_>
<_mailto:sven@efftinge.de_> 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@eclipse.org_
_https://dev.eclipse.org/mailman/listinfo/m2t-dev_
_______________________________________________
modeling-pmc mailing list
_modeling-pmc@eclipse.org_
_https://dev.eclipse.org/mailman/listinfo/modeling-pmc_
_______________________________________________
gmf-dev mailing list
_gmf-dev@eclipse.org_
_https://dev.eclipse.org/mailman/listinfo/gmf-dev_
_______________________________________________
m2t-dev
mailing
list
_m2t-dev@eclipse.org_
_https://dev.eclipse.org/mailman/listinfo/m2t-dev_
_______________________________________________
m2t-dev
mailing
list
_m2t-dev@eclipse.org_
_https://dev.eclipse.org/mailman/listinfo/m2t-dev_
_______________________________________________
m2t-dev
mailing list
_m2t-dev@eclipse.org_
_https://dev.eclipse.org/mailman/listinfo/m2t-dev_
_______________________________________________
m2t-dev mailing list
_m2t-dev@eclipse.org_
_https://dev.eclipse.org/mailman/listinfo/m2t-dev_
------------------------------------------------------------------------
_______________________________________________
modeling-pmc mailing list
_modeling-pmc@eclipse.org_
_https://dev.eclipse.org/mailman/listinfo/modeling-pmc_
------------------------------------------------------------------------
_______________________________________________
modeling-pmc mailing list_
__modeling-pmc@eclipse.org__
__https://dev.eclipse.org/mailman/listinfo/modeling-pmc_
------------------------------------------------------------------------
_______________________________________________
modeling-pmc mailing list_
__modeling-pmc@eclipse.org__
__https://dev.eclipse.org/mailman/listinfo/modeling-pmc________________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
------------------------------------------------------------------------
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
