Re: [m2m-dev] Possible migration of UMLX to QVT

[Quentin Glineur <quentin.glineur@xxxxxxx>]

Hi Ed,

Please also excuse me for my late answer: I was on holidays ;)

Ed Willink a écrit :

Hi Quentin

Sorry for the late reply; I've been having trouble over domain renewal with with my ISP.

I think I can adjust to most of the omissions.

The QVT preferences can probably be deduced from EMF content types.

But: Of the current Model Registry activities:

a) ensuring EMOF is accurately loaded regardless of extension.
This is no longer required; I have succeeded in using content
types and an unmodified ResourceSetImpl for EMOF-based
to/from Ecore-based QVT conversions in M7.

b) defining URI aliases; this is not essential for perhaps QVTc or QVTr
but is nonetheless useful for all QVT*.

c) defining model-name resolutions; something like this is essential...

QVTr or QVTc transformations refer to models by name

e.g. RelToCore (in valid form; not as in the FAS)

transformation relToCore(relations:{qvtrelation,qvttemplate,qvtbase,essentialocl,emof}, core:{qvtcore,qvtbase,essentialocl,emof})
{
...
}

There is no clue as to where any of these model names reside.
The Model Registry or equivalent functionality provides the resolution.

a) A GUI to maintain a persistent set of registrations

b) the persistent registrations in the
.settings/org.eclipse.gmt.umlx.registry.modelregistry
model

c) an API to support use of those registrations.

NB. The Model Registry maintains only registrations, the models
are stored elsewhere.

  

OK, I agree with you about the necessity of a metamodel registry.

-----

The unparser is a relatively simple class that supports AST to CST conversion and
so allow the editor to work forwards from CST to AST or backwards.

-----
  

Thanks for the explanations!

I will describe here our goals and therefore the items you developed 
that could take part in the Declarative QVT project if aligned.

- We shall have the Declarative QVT projects define as being plug-ins.
    

I'm not sure what you mean.

Obviously all of the QVT-Declarative component will be plug-ins.

When I develop a transformation as a user, I should be using a project
with the QVTr or QVTc Nature to provide the building. I would not
call these plug-ins, though they could be to support developer/customer
usage.
  

But developing a plugin for a transformation leverage the eclipse installation and dependency mechanism.
It allows to pack and distribute it cleanly (see below).

- Those projects have a "transformation" folder and a "build" folder.
- Files suffixed by "qvtr" or "qvtc" in the transformation folder are 
automatically compiled into the build folder (hidden)
    

The UMLX QVTr and QVTc natures do this build, but without separating folders.
Easy fix. Should really be subject to a user/project preference.

  

Definitively.

- A transformation may re-use some others one inside the same 
project or 
inside another which is defined in the dependencies (MANIFEST.MF)
    

I don't think this is right.

MANIFEST.mf (and somethimes plugin.xml) contains definitions exported
to a plugin for distribution or use in another Eclipse session.

Tools such as JDT that have information for use in the current Eclipse
session store that information in .project, .classpath, .settings/*,
.launches/*, ...

I know of no tool that uses MANIFEST.mf in the current session.
It describes what is published in the JAR.
  

We want the execution to be runnable from the current eclipse session *and* in another one.
The use for such a mechanism is mainly the extension of transformation of another project.
The path information are stored in a ".transformationpath" with an entry managed by the manifest.mf to point the ".transformationpath" of the dependencies.
(much like "org.eclipse.pde.core.requiredPlugins" for the Java ".classpath").

Also providing additional information in MANIFEST.mf requires extending
the Manifest editor if challenging synchronisation issues are to be avoided
between the PDE and a QVT manifest editor.

The Model Registry maintains model registrations as a model in
.settings/org.eclipse.gmt.umlx.registry.modelregistry.
This can also be used for transformation model resolution.

  

- An execution action is provided from the source file (calling the 
corresponding compiled version)
    

Making this elegant and flexible is hard. I've avoided looking at this since
OMELET was killed off by MDDi.

There needs to be a nice simple API to allow easy invocation of
transformations from other model integration tools.

  

- Transformations can be integrated in Eclipse as plug-in (adding a 
transformation action on models conforming to a managed metamodel).
    

This is certainly a useful option when distributing fully developed
transformatiuons for use almost as black boxes.

However many/most initial users may be concurrent developers of 
meta-models and transformations, and so a plug-in context is not
important.

For instance ATL users develop transformations in an ATL
project. I'm not sure that they would like having to package their
ATL transformations up in a plugin and start another Eclipse session
in order to execute them.
  

1) Many people express such a need (may they be model transformation new comers, industrialists or developers in need of an integration of the transformation they wrote).
2) This will be done step by step thanks to anticipation.

	Regards

		Ed Willink


_______________________________________________
m2m-dev mailing list
m2m-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-dev

  

Regards,

Quentin Glineur

begin:vcard
fn:Quentin GLINEUR
n:GLINEUR;Quentin
org:Obeo - Model Driven Company;Research and Development
adr;quoted-printable:;;2 rue Robert Schumann;Rez=C3=A9;;44400;France
email;internet:quentin.glineur@xxxxxxx
title:MDA Consultant
x-mozilla-html:TRUE
url:http://www.obeo.fr
version:2.1
end:vcard