Community
Participate
Working Groups
Build Identifier: 20120216-1857 It seems to be a gap that QVTo can happily be used to create model instances for every diligently implemented ecore metamodel either in standard XMI Format or even textual when using a fine component like EMFText, while QVTo Transformations can not be used to create a QVTo transformation file. On evolving metamodels it might be helpful to have a transformation that produced a statistic transformation. Or it might help to generate detailed identity transformations or "hello world"-ish construction transformations to quick start transformation development on your new metamodel. For textually represented metamodels is is easy to convert an example file into an acceleo or JET2 template, while it is tedious to write the corresponding *.qvto-Fragment. Generating it thru a transformation would help QVTo to get comparable on that issue to M2T. Last but not least, the presentation from Nicolas Rouquette http://www.omg.org/news/meetings/tc/dc-12/special-events/pdf/Rouquette-QVTo.pdf seems to highlight on slide 11 that this feature is needed to reach full OMG QVTO compliance on level "SyntaxExportable". Reproducible: Always Steps to Reproduce: 1. Try the following "Hello World" transformation ================================================= modeltype qvto uses "http://www.eclipse.org/QVT/1.0.0/Operational"; transformation Test2QVTo( out qvtoModel : qvto); main() { map createMainUnit('Hallo Welt'); } mapping createMainUnit(cuName : String) : qvto::expressions::OperationalTransformation { result.name := cuName; result.entry := object qvto::expressions::EntryOperation { name := 'Einstieg'; }; } ============================================= 2. Or try following copy transformation on any qvto file ============================================= modeltype qvto uses "http://www.eclipse.org/QVT/1.0.0/Operational"; transformation QVToCopy( in qvtoIn : qvto, out qvtoOut : qvto); main() { qvtoIn.rootObjects()[qvto::expressions::Module]->map theMap(); } mapping qvto::expressions::Module::theMap() : qvto::expressions::Module { init { result := self; } } mapping qvto::expressions::Library::theMap() : qvto::expressions::Module { init { result := self.deepclone().oclAsType(qvto::expressions::Library); } } mapping qvto::expressions::OperationalTransformation::theMap() : qvto::expressions::Module { init { result := self.deepclone().oclAsType(qvto::expressions::OperationalTra nsformation); } } ============================================= 3. In both cases there is a diagnostic ok message on the console but no qvto resource gets written (unsurprisingly after reading the source code)
QVTo is able to apply transformation to QVTo models, but they cannot be loaded for execution. The major problem of loading should be solved soon by an imminent mega-patch from JPL that allows the textual and abstract QVTo files to be handled separately. Then a minor irritation will be that the prevailing pragmatic Eclipse QVTo AST deviates a little from the OMG QVTo AST available in the org.eclipse.qvt plugins. This deviation should be resolved as part of work to auto-tool QVTO from a fuller OMG specification.
Created attachment 260709 [details] Git patch of implementation and junit tests
The original title "QvtOperationalResourceImpl.save() not implemented" was very misleading since QvtOperationalResourceImpl.save() is implemented by EMF. It is just the *.qvtox save that was not exposed through the UI. This led to my confusing comment #c2. An unparser is a differently useful functionality, but it should not be activated by QvtOperationalResourceImpl.save() since this is a standard XMI save API. Not even with a save option. I think the unparser/pretty-printer needs to be a separate component that can be invoked to convert a QvtOperationalResource to a String so that users can save as suits them. Changing QvtOperationalResourceImpl.save() itself risks breaking existing users through a semantic API change.
1. QvtOperationalResourceImpl.save() is clearly "implemented" in there and not in EMF. Once as throwing an UnsupportedOperationException and once as an empty method with a single line of comment. I think both "implementations" qualify as 'not implemented'. 2. qvtox can happily be saved even through the ui. That is absolutely not the point of this bug report. 3. It would probably be better when qvto and qvtox files would be handled by different Resource classes. But as it stands the qvto Extension is registered against QvtOperationalResourceFactoryImpl which only produces QvtOperationalResourceImpl. As long as that is not changed, I think, QvtOoperationalResourceImpl is perfectly responsible for persisting qvto-files.
(In reply to Ed Willink from comment #3) > The original title "QvtOperationalResourceImpl.save() not implemented" was > very misleading since QvtOperationalResourceImpl.save() is implemented by > EMF. It is just the *.qvtox save that was not exposed through the UI. This > led to my confusing comment #c2. I don't think you're correct at this point. QVTO provides two completely separate implementations for model interchange. Each has it's own registration with "org.eclipse.emf.ecore.extension_parser". The first is for '.qvtox' which is backed by 'org.eclipse.m2m.internal.qvt.oml.compiler.ExeXMIResource' class and provides support for both saving and loading. Second is for '.qvto ' which is backed by 'org.eclipse.m2m.internal.qvt.oml.runtime.resource.QvtOperationalResourceImpl' class and for the moment provides support only for loading. Namely corresponding method in 'QvtOperationalResourceImpl' look like: @Override public void save(Map<?, ?> options) throws IOException { // resource operates as read-only } I believe that 'QvtOperationalResourceImpl.save()' is the exact target for '.qvto' unparsing functionality. Execution of unparsing (controlling with the special option) can be safely integrated into 'QvtOperationalResourceImpl.save()'. > > An unparser is a differently useful functionality, but it should not be > activated by QvtOperationalResourceImpl.save() since this is a standard XMI > save API. Not even with a save option. > > I think the unparser/pretty-printer needs to be a separate component that > can be invoked to convert a QvtOperationalResource to a String so that users > can save as suits them. Changing QvtOperationalResourceImpl.save() itself > risks breaking existing users through a semantic API change.
(In reply to Uwe Ritzmann from comment #4) > 1. QvtOperationalResourceImpl.save() is clearly "implemented" in > there and not in EMF. Once as throwing an UnsupportedOperationException and > once > as an empty method with a single line of comment. > I think both "implementations" qualify as 'not implemented'. Agree. > > 2. qvtox can happily be saved even through the ui. That is absolutely not > the point of this bug report. Agree. > > 3. It would probably be better when qvto and qvtox files would be handled > by different Resource classes. But as it stands the qvto Extension is > registered > against QvtOperationalResourceFactoryImpl which only produces > QvtOperationalResourceImpl. As long as that is not changed, I think, > QvtOoperationalResourceImpl is perfectly responsible for > persisting qvto-files. As I already noted in comment#5 '.qvto' and '.qvtox' are handled by different Resources ('QvtOperationalResourceImpl' and 'ExeXMIResource' appropriately).
Pushed unparsing visitor to master for Neon M7. Commit id: 1581db84095f169482c8ae278c5ad4b8e7f99c60
Pushed junit tests for the new functionality to master for Neon M7. Commit id: 52ed42b159fd9819a179503f72ebf54569c45071
(In reply to Sergey Boyko from comment #8) > Pushed junit tests for the new functionality to master for Neon M7. > Commit id: 52ed42b159fd9819a179503f72ebf54569c45071 The unit tests involve a major code duplication: most of the tested *.qvto files in the unparserTestData/source folder are hard-copied from other folders, especially parserTestData/models and parserTestData/sources. This is unncessary because the tests can easily be configured so that they reuse the original test files. The consequences of copying are demonstrated by bug 573718, which caused the *.qvto file for bug 325192 to evolve without being propagated to the copy.
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/195360
