org.eclipse.gmt.umlx.eqvt -> org.eclipse.m2m.qvt.relations.ecore
org.eclipse.gmt.umlx.eqvtbase...
org.eclipse.gmt.umlx.eqvtcore...
org.eclipse.gmt.umlx.eqvtrelation...
org.eclipse.gmt.umlx.eqvttemplate....
org.eclipse.gmt.umlx.eqvt.edit -> org.eclipse.m2m.qvt.relations.ecore.edit
org.eclipse.gmt.umlx.eqvtbase.provider
org.eclipse.gmt.umlx.eqvtcore.provider
org.eclipse.gmt.umlx.eqvtrelation.provider
org.eclipse.gmt.umlx.eqvttemplate.provider
org.eclipse.gmt.umlx.eqvt.editor -> org.eclipse.m2m.qvt.relations.ecore.editor
org.eclipse.gmt.umlx.eqvtbase.presentation
org.eclipse.gmt.umlx.eqvtcore.presentation
org.eclipse.gmt.umlx.eqvtrelation.presentation
org.eclipse.gmt.umlx.eqvttemplate.presentation
?? org.eclipse.gmt.umlx.qvt.ui -> org.eclipse.m2m.qvt.relations.ui
MDT-QVT-OM
org.eclipse.gmt.umlx.qvt -> org.eclipse.m2m.qvt.oml.emof
org.eclipse.gmt.umlx.ImperativeOCL...
org.eclipse.gmt.umlx.QVTOperational....
org.eclipse.gmt.umlx.eqvt -> org.eclipse.m2m.qvt.oml.ecore
org.eclipse.gmt.umlx.imperativeocl...
org.eclipse.gmt.umlx.eqvtoperational....
org.eclipse.gmt.umlx.eqvt.edit -> org.eclipse.m2m.qvt.oml.ecore.edit
org.eclipse.gmt.umlx.imperativeocl.provider
org.eclipse.gmt.umlx.eqvtoperational.provider
org.eclipse.gmt.umlx.eqvt.editor ->
org.eclipse.m2m.qvt.oml.ecore.editor
org.eclipse.gmt.umlx.imperativeocl.presentation
org.eclipse.gmt.umlx.eqvtoperational.presentation
This is a depressing amount of
redistribution. Some savings can be made by folding
provider and presentation packages into
main model plug-ins.
I'm not certain of the value of the Java
generation of the EMOF-based plugins. In my
experience their existence just provides an
opportunity to inadvertently use
non-adapted models. If Java generation is
not performed then the corresponding
plugins contain no more than a strict OMG
Ecore that could be put in the Ecore-based
plugin instead. I gave up generating the
EMOF-based edit plugins long ago, since I had no
time to do better than the default
reflective editor.
Following all the above savings, there
could be just a single QVTR and a single QVT-OM plug-in.
The
models are pretty stable. I probably make about 1 change per month as
some
further
discrepancy comes to light whose resolution is either so obvious, or
justified
by
one of the many ambiguities that QVT 1.0 offers. A larger group of
changes may
be
appropriate if the RTF ever starts discussions.
The
Ecore-EMOF adapters had a significant revision two months ago to
accommodate
the
multiple extension of QVTOperational. I expect a further revision to
exploit EMFs
new
contentHandler/Type extension points hopefully eliminating the need for
a
derived
ResourceSet to mediate the EMOF-Ecore adapting. I would expect to do a
general
cleanup to celebrate moving from an IP-suspect black hole, to a location
were
a much greater user base is dependent on the code.
Clearly
this is all too late for the 3.4M6 API freeze, so presumably we're
looking
at
a 3.5M6 freeze.
I
would expect to be a committer for each of the plugins to which the
models are
reallocated,
at least until 3.5M6. To keep the committer rights and project
negotiations
more
manageable I think it would be best to locate all
EMF/OCL bits in QVTR until
at
least 3.5M5. Around 3.5M4 a decision could be made whether
to migrate to EMF/OCL or not.
If
a migration changes package names, these should affect only the model
plugins;
externally
the models just work.
