[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [qvto-dev] Initial Xtext/Pivot handover
|
Hi Ed,
Thanks for this initial insight. Very helpful.
Finally I've started to do some bits concerning QVTo. Some comments:
- Now I'm subscribed to QVTo DEV newsgroup.
- It took me some time to reach the QVTo project information. The "About
this project" link from the Eclipse QVTo web page didn't work. I finally
found that for eclipse records, the project is mmt.qvt-oml rather than
mmt.qvto. I'm not quite sure how to fix that. If you do so, lease let me
know it. If something needs to be changed at somewhere
www.eclipse.org/mmt.git repository, I recall that I'm only committer at
mmt.qvt-oml project so I won't be able to do it
- As QVTo and MMT project leader, I'm wondering if you want to raise the
suggestion of aligning project ids with the QVTd ones. I'm not very fond
of unnecessary and potentially harmful changes, though. On the other
hand, I've noticed that you have started to do so in the plugin names,
e.g org.eclipse.qvto.examples.xtext.imperativeocl which deviates from
the current QVTo project plugins (which use qvt.oml).
Some other comments in-line below:
On 04/01/2013 11:04, Ed Willink wrote:
Hi Adolfo
On 04/01/2013 08:15, Ed Willink wrote:
I have very preliminary org.eclipse.qvto.pivot.imperativeocl and
org.eclipse.qvto.xtext.imperativeocl plugins that I could commit, but
I guess they must be ".examples" since their first release will be an
experimental adjunct to a non-incubation project (only QVTd can skip
the ".examples'" phase). I'll do a quick rename and commit them. I
don't think we need a QVTo Tools build. There will clearly be nothing
ready for release with Kepler; for Kepler+1, I hope we can just ship
both together, and maybe in Kepler+2 drop the ".examples".
I've done a quick rename and pushed
org.eclipse.qvto.examples.pivot.imperativeocl and
org.eclipse.qvto.examples.xtext.imperativeocl to master. In so far as
your new work is 100% in examples/... it can be pushed to master quite
regularly; no need for an asbh/397429 branch that doesn't get merged
till 2015. [I'm inclined to switch to asbh/... and edw/... rather than
bug/... as an aid to understanding what is happening with branches.]
I'm OK with the branches name convention suggestion.
I've created https://bugs.eclipse.org/bugs/show_bug.cgi?id=397429 as a
catchall for the bread and butter part of your EngD. You can create one
more (or many more) for the innovative part; check with Dimitris in case
you need to preserve some temporary secrecy on your innovations.
org.eclipse.qvto.examples.pivot.imperativeocl is plausible. It GenModels
ok, but there is no copyright/dynamicTemplate to define the Willink
Transformations + York copyright.
I've started to do some work in the pivot.imperativeocl plugin since it
provoked some compilation errors due to the missing generated classes.
- Are you looking for a dynamic template to automatically include the
last modified year for the copyright ? Otherwise the static text that
you may use in the genmodel copyright attribute should suffice. At list
I've set
- I've had some errors when opening the genmodel file, perhaps, due to
the use of absolute platform:/plugin URIs for the related genmodels
(Ecore and Pivot). If I reload the genmodel (right click on genmodel ->
reload) using the wizard, relative URIs are used instead and the editor
doesn't complain. Any comment about using relative URIs ?
- The generated code complains (warning) about the use of a @Deprecated
pivot.util.Nameable. Any documentation about the deprecation cause?
- I've tried to push my changes to master. However and error occurred.
Investigating in the eclipse server I see the following rights in the
mmt folder:
drwxrwsr-x 7 wpiers modeling.mmt 4096 2012-09-20 16:32
org.eclipse.atl.git
drwxrwsr-x 7 root modeling.mmt 4096 2012-09-20 11:38
org.eclipse.atl.git.back
drwxrwsr-x 7 ewillink modeling.mmt.qvtd 4096 2011-09-22 14:42
org.eclipse.qvtd.git
drwxrwsr-x 7 ewillink modeling.mmt 4096 2012-06-19 13:59
org.eclipse.qvto.git
As commented above I dont have any right on modeling.mmt, but in any
case my bet is that the qvto GIT repository should have
modeling.mmt.qvt-oml as its unix group.
The autogenerated code has no accept()
Previously, I need a derived Visitor to visit the new ImperativeOCL
expressions. I remember that you used some MDE tooling to generate the
visitors, so I'll start to play with the OCL one.
method in each Impl class. The underlying EMF limitation has now been
fixed so
org.eclipse.ocl.examples.build.utilities.VisitableAcceptGenerator might
now work if it was uncommented in
org.eclipse.ocl.examples.build/GeneratePivotModel.mwe2. This might be a
useful introduction to MWE2 and the
org.eclipse.ocl.examples.build.GenerateXtextModels approach. You need
something rather similar to
org.eclipse.qvtd.build.mwe2/GenerateQVTModels.mwe2.
Ok, this looks like what I need to look into. I'll have a look to it.
NB. org.eclipse.ocl.examples.build/GenerateAll.mwe2 should work but it
doesn't; there is a 'trivial' interaction to sort out in the various
scripts startups.
Well I'll see what I can do.
org.eclipse.qvto.examples.xtext.imperativeocl is very much a work in
progress; you can see commented out LPG remnants in the Xtext files
where they have yet to be converted. The committed files are not
error-free. The CST seems to be set to autogenerate; odd; it shouldn't
be, maybe back in June, I was having a bad Xtext day and switched to
automated just to try and get something working. My vague recollection
is that I started on a translation of the Eclipse QVTo LPG grammar to
Xtext, since it was a working grammar, got depressed by its divergence
from the OMG QVTo grammar and so switched to a translation of the OMG
QVTo grammar to Xtext and realized that ImperativeOCL.xtext needed to be
done first to modularize the grammars; then it was time for bed. Once we
have a runnable Xtext QVTo editor, we need to go back to the old Eclipse
QVTo grammar to discover any extra syntaxes or corrected syntaxes.
I'll probably need some time to familiarize with Xtext again. My
experiments with Xtext I did in the past were quite trivial ;)
Cheers,
Adolfo.
Regards
Ed
