[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)
|
Rich,
note that I was a bit surprised and sad about your response, as it
sounds really annoyed.
I understand that you want to create your own template language
component, as you've made bad experiences with relying on others.
Please, don't take my comments as arguments against creating such a
component (I'm ok with doing so).
Anyway, I think there are some points in it worth to discuss.
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.
Again, oAW used to be developed by volunteers, which did all the work
in their spare time.
Two years ago some of these volunteers thought it would be great to
move Xpand and the workflow engine to Eclipse. I also think it is a
good idea, but undoubtly it was too early since we (the committers of
oAW) couldn't meet the promises.
Since february 2008 things are different. itemis AG has employed a lot
of the committers in order to help making these components good
eclipse citizens.
Still I understand that you want to see some action before again rely
on promises.
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.
You didn't just replace the parser generator technology, but removed
some very important features and added things as it seemed fit.
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.
Ok, good point.
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.
Yes, I thought it was time to work on a unique identity (eclipse
modeling).
But maybe it's just too early.
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).
It's not eliminated just because there is another template language
not using it.
Primarily, Xtend is not an M2M language but a language to write helper
functions for code generation.
We just added a small feature (create keyword) to make it convenient
for model transformation also.
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.
Sure.
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.
It was because there was no "Essential OCL" standard at that time.
When we developed Xpand there was the "old OCL" only. With UML2
classes as type system,
and a lot of strange things with regards to associations, etc. in it,
it would have been impossible to map it to an ecore-like type system.
In addition no one used OCL at that time. So we decided to study the
problem domain, study programming languages (also OCL) and
come up with a simple language with a syntax most of our users are
used to (Java-like).
The way I see it, we're providing a nice migration for Xpand and
improving
its capabilities.
You removed important capabilities (e.g. the type system abstraction,
the ability to modify models).
Also the tooling lacks behind what we have (no debugging, refactoring,
etc.)
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?
No we don't reject the inclusion of standards.
But we won't include something *only* because it's a standard.
Especially modeling related OMG standards tend to be unnecessary
complex.
We should remember that it is essential OCL we are talking about which
was developed
because of essential MOF (it's type system) which was driven by EMF's
Ecore.
This is how good standards evolve, based on practice-proven things.
To sum it up, essential OCL seems to be a good thing. As I said, we
promised not to break API.
As we don't want this to be another empty promise, we can't migrate to
eOCL right now.
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.
Understandable. And you can't be sure.
But as I said chances are good since we're no longer developing in our
spare time.
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.
I really have thought about starting such a survey.
Would be interesting indeed.
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.
This wasn't meant to be a political argument.
I just wanted to make sure, that you're aware of the huge user community
xpand will bring to eclipse modeling, once we've released the first
version under M2T.
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.
Yes, it's especially painful because people use this in political
discussions again and again.
The reason why we haven't yet migrated the community is because the
users currently use the Xpand from oAW.
We want the community to migrate to M2T/Xpand when there are release
at M2T/Xpand.
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.
Yes, and those technologies contain a lot of great ideas.
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?
I understand that you don't want to rely on promises again.
GMF is and was one important consumer of Xpand. And we've talked a lot
about features and your
needs (via mail and in bugzilla). But you're right that we hadn't had
the needed resources to
create a working M2T/Xpand.
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?
I don't.
I think EOCL is very similar to todays Xpand expression language and
it's not a bad idea in general to migrate to EOCL.
But in future we might have new ideas about how such a language
ideally should look like.
How should we improve on it if we're stuck to specifications?
It's a good thing to have these standards implementations (and we
already have them).
Don't we also want to allow evolution?
regards,
Sven
