Separate XMI transformations from concrete syntax transformations

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 537555 | | Status | NEW | | Importance | P3 minor | | Reported | Aug 01, 2018 02:54 EDT | | Modified | Aug 02, 2018 09:54 EDT | | Reporter | Christopher Gerking |

Description

The mechanism to load an XMI transformation from .qvtox is messily intertwined with the compilation of concrete syntax transformations from .qvto files. This results in a conditional dispatcher inside CstTransformation which (as its name suggests) should actually handle concrete syntax only.

I propose a clear separation between the current CstTransformation (perhaps renamed ConcreteSyntaxTransformation) and an XmiTransformation, perhaps with a common superclass to share code. In particular, the XmiTransformation shouldn't need a compiler to work.

[eclipse-qvt-oml-bot]

By Ed Willink on Aug 01, 2018 03:39

The principle seems right, but...

The *.qvtox should indeed be executable without CST and so XmiTransformation is a possible name. AbstractSyntaxTransformation might be better.

The *.qvto needs the CST, but the user should not need to know about the underlying CST. ConcreteSyntaxTransformation steps away sensibly from CST.

Eliminating the org.eclipse.m2m.qvt.oml.cst.parser dependency from org.eclipse.m2m.qvt.oml gives 250 errors in that plugin. I think that you will find it difficult to sort this out without refactoring the Classic Ecore OCL for which the LPG parser is used by the root org.eclipse.ocl plugin. The Classic OCL will not be refactored since the replacement Pivot OCL already factors the parser out into the org.eclipse.ocl.xtext.* plugins.

Beware, once you disentangle CS/AS functionality you need to ensure that error messages appear once. Anything that can be reported as an AS WFR violation needs to be reportable by the AbstractSyntaxTransformation validate() method and so the CS2AS should only diagnose what cannot be translated to the AS to avoid duplicate reporting from CS2AS and AS WFRs.

While this Bugzilla is very well intentioned, I suspect that you are going to encounter numerous problems for ultimately only a small aesthetic benefit. Given that Classic OCL inflicts LPG on the users anyway, what saving can QVTo really offer? Have a look at other solutions.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Aug 02, 2018 09:54

(In reply to Ed Willink from comment #1)

While this Bugzilla is very well intentioned, I suspect that you are going to encounter numerous problems for ultimately only a small aesthetic benefit. Given that Classic OCL inflicts LPG on the users anyway, what saving can QVTo really offer? Have a look at other solutions.

My initial intention was just to refactor the conditional dispatcher out of class CstTransformation, thereby separating transformations that need the compiler from those that don't. I did some quick and dirty prototyping and that seems to work very well.

However, after having done the refactoring, it seems more appropriate to establish the separation at the Resource level. In other words, we could just use a ResourceSet to load arbitrary transformation URIs, relying on the underlying registrations to decide whether a default XMI resource is to be created or a special QvtOperationalResourceImpl that needs the compiler to load. Prototyping this solution makes a couple of test cases fail, but these problems seem to be manageable. Anyway, I won't follow this approach before the major changes for bug 537041 have made it to master, if at all.