Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
MMT/QVTo/New and Noteworthy/2019-09
- 1 3.10.0 (September 2019)
- 2 3.10.1 (December 2019)
- 3 3.10.2 (June 2020)
- 4 3.10.3 (March 2021)
- 5 3.10.4 (June 2021)
- 6 3.10.5 (December 2021)
- 7 3.10.6 (March 2022)
- 8 3.10.7 (June 2022)
- 9 3.10.8 (December 2023)
3.10.0 (September 2019)
Eclipse QVT Operational New and Noteworthy items for the 2019-09 (3.10.0) release.
3.10.0 Milestone 3
550053 The root QVTo metamodel EPackage is now statically rather than lazily registered
3.10.1 (December 2019)
Eclipse QVT Operational New and Noteworthy items for the 2019-12 (3.10.1) release.
Nothing has changed, but changes to the Eclipse Foundation infrastructure merit a maintenance release.
3.10.2 (June 2020)
Eclipse QVT Operational New and Noteworthy items for the 2020-06 (3.10.2) release.
3.10.2 Milestone 1
561707 Regression for implicitly contained elements fixed
3.10.2 Milestone 2
562732 Java 8 now explicitly rather than implicitly required for UI functionality
3.10.3 (March 2021)
562175 When creating a new QVTo plug-in project, the directory for *.qvto files is now automatically registered by adding an extension to the plugin.xml file. Imports of *.qvto files can thus be resolved against this directory in an Eclipse environment.
565747 QVTo now aims to automatically infer the namespace URIs needed to resolve blackbox operations. For example, to resolve a blackbox operation that uses types from the Ecore metamodel, the corresponding Java class no longer needs to be annotated with
566216 The Java blackbox resolution now conforms to the Liskov substitution principle. This makes it possible for a Java blackbox method to return a subtype of the QVTo return type or to accept supertypes of the QVTo parameter types.
566230 The Java blackbox resolution now takes into account the argument types of parameterized types. When a Java blackbox method uses a parameterized type, its argument types must be compatible with those of the corresponding QVTo type, which prevents invalid bindings between QVTo types and Java types.
3.10.4 (June 2021)
This release improves the support for blackbox development in the workspace:
573449 It is now possible to resolve blackboxes against dynamic metamodels from the workspace. This is achieved by analyzing the corresponding GenModel.
573752 Resolving blackboxes is now possible even if the underlying metamodels are located in required bundles.
570407 QVTo can now handle metamodels that use a relative URI (such as
../../org.eclipse.emf.ecore/model/Ecore.ecore) to reference other metamodels. If they are not present in the workspace, the referenced metamodels are searched in the corresponding package registry.
566236 Loading *.qvto units in standalone mode is now possible even if the path to a unit contains whitespace.
3.10.5 (December 2021)
This release provides further improvements to the support for blackbox development in the workspace:
573449 Blackboxes may now use dynamic metamodels from the workspace.
574706 Blackbox class loading and analysis improved.
573718 'out' parameters are no longer cloned as part of the trace.
577310 Cyclic build paths no longer crash the QVTo buillder.
3.10.6 (March 2022)
This release provides further improvements to the support for blackbox development in the workspace and a significant simplification in the import of metamodels.
Whereas it used to be necessary to use a modeltype statement to import a model name such and then map the model name to the actual model in the .settings/org.eclipse.m2m.qvt.oml.mmodel.urimap, it is now possible for the modeltype to reference the actual model directly; the .settings/org.eclipse.m2m.qvt.oml.mmodel.urimap file is now obsolete.
3.10.6 Milestone 1
573449 Java blackboxes imported from the workspace now reload correctly when changing the underlying Java implementation.
3.10.6 Release Candidate 1
577618 Metamodels may be directly imported using platform URIs. This eliminates the need to set up metamodel mappings between namespace URIs and platform:/resource URIs when developing transformations in the workspace.
577992 Blackboxes based on dynamic metamodels can now be imported by a QVTo unit and executed in the workspace.
578625 Transformations importing blackboxes from the workspace may be serialized to *.qvtox files.
578955 Blackboxes in the workspace may be imported with access or extends.
3.10.7 (June 2022)
This release provides further improvements to the support for blackbox development in the workspace.
3.10.7 Milestone 3
507955 Transformations deployed to a plug-in can now import Java blackboxes that are on the classpath of that plug-in. When execting a transformation using the
TransformationExecutor class, it is no longer strictly required to register the blackbox with the javaBlackboxUnits extension point.
566236 Loading *.qvto units from a path that contains whitespace is now tested.
3.10.8 (December 2023)
This release improves the diagnostics returned by QVTo's Java API. In case of an assert expression that fails during execution, the
ExecutionDiagnostic returned by
TransformationExecutor now includes a proper severity and accompanying message (as indicated by the failing assertion). This enables error messages and warning messages to be passed from QVTo to Java. In case of a log expression, the accompanying message is added to the diagnostics with OK severity.
3.10.8 Milestone 3
525852 UI tests trigger an initialization of the OCL standard library to prevent race condition.
543009 Standalone tests are executed using Maven Surefire.
566236 Transformation paths may use weird whitespace.
581992 Transformation assert failures now have error or warning severity and an accompanying message (if available).
3.10.8 Release Candidate 1
326871 Separate plugins used for test blackboxes.
577992 Blackbox can now be loaded from an executable XMI (*.qvtox) resource.
582635 Download ZIP now includes test classes.
3.10.8 Release Candidate 2
537527 Compiled XMI (*.qvtox) is used in test cases with inter-project references.