[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2m-dev] QVT models component
|
Hi Ed,
Quentin properly summarized the new committer policy.
I am glad that we now have a clean solution for the contribution of
your QVT work into M2M.
Thanks to you, we are making significant progress.
Best regards,
Frédéric
On Mon, Mar 31, 2008 at 4:46 PM, Quentin Glineur
<quentin.glineur@xxxxxxx> wrote:
>
> Hi Ed,
>
> The schema you give for QVTR seems quite good to me (the redistribution
> does not frighten me).
> As I told previously, at this time, we are only ready to accept the EQVTR
> contribution (Base, Template, Core, Relations)
>
> Our policy is to follow the regular way:
> - patch submission for the contribution
> - patch submission for the maintenance
> Once enough support in M2M is provable, election for M2M committer status.
>
> Regards,
>
> Quentin Glineur
>
> Ed Willink a écrit :
>
>
> Hi Quentin and Radek
>
> If Radek's happy with QVT-OM having weak dpendencies on QVTR then a possible
> repositioning of
> current UMLX QVT functionality
>
> Possible New Project
> Existing UMLX Plugin -> Possible Replacement Plugin
> Existing Package
>
> ??EMFT-AdaptedModels or MDT-QVTR ??
> org.eclipse.gmt.umlx.common -> org.eclipse.emf.adaptedmodels
>
>
> org.eclipse.gmt.umlx.alien.adapter
> org.eclipse.gmt.umlx.alien.mapping
>
> org.eclipse.gmt.umlx.xmi.util
>
>
> org.eclipse.gmt.umlx.eqvt -> org.eclipse.emf.adaptedmodels.ecore
> org.eclipse.gmt.umlx.emof.util
>
>
>
> org.eclipse.gmt.umlx.qvt -> org.eclipse.emf.adaptedmodels.emof
> org.eclipse.gmt.umlx.EMOF...
>
>
>
>
>
> ?? MDT-OCL or MDT-QVTR ??
>
>
>
>
>
>
> org.eclipse.gmt.umlx.qvt -> ?? org.eclipse.ocl.ecore.emof
>
>
>
>
>
> org.eclipse.gmt.umlx.EssentialOCL...
>
> ??org.eclipse.gmt.umlx.FullOCL... org.eclipse.gmt.umlx.eqvt ->
> ?? org.eclipse.ocl.ecore.ecore
>
>
>
>
>
>
>
>
>
> org.eclipse.gmt.umlx.essentialocl.util
>
>
>
>
>
>
> org.eclipse.ocl.edit
> org.eclipse.ocl.ecore.edit
>
> MDT-QVTR
> org.eclipse.gmt.umlx.qvt -> org.eclipse.m2m.qvt.relations.emof
> org.eclipse.gmt.umlx.QVTBase...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> org.eclipse.gmt.umlx.QVTCore...
>
>
> org.eclipse.gmt.umlx.QVTCorePlus...
>
>
> org.eclipse.gmt.umlx.QVTRelation...
> org.eclipse.gmt.umlx.QVTTemplate....
>
>
>
>
> 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.
>
> If you want to make the extra arrangements for EMF and OCL project access
> from the outset
> then I leave that up to you (or Frederic). In the meantime I'll work on
> supporting EMOF Comments,
> inverse navigation role names and EMF content types within the UMLX project.
> When someone
> notifies me of alternate locations I'll move code there.
>
> Regards
>
> Ed Willink
> ________________________________
>
> _______________________________________________
> m2m-dev mailing list
> m2m-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2m-dev
>
>
> _______________________________________________
> m2m-dev mailing list
> m2m-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2m-dev
>
>
