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.