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

["Ed Willink" <ed@xxxxxxxxxxxxx>]

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.

-----

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.

-----
> 
> 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.

> - 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.

> - 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.

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.

	Regards

		Ed Willink