View source for MMT/QVTo/New and Noteworthy/2019-09

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

[https://bugs.eclipse.org/550053 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==

[https://bugs.eclipse.org/561707 561707] Regression for implicitly contained elements fixed

==3.10.2 Milestone 2==

[https://bugs.eclipse.org/562732 562732] Java 8 now explicitly rather than implicitly required for UI functionality

=3.10.3 (March 2021)=

[https://bugs.eclipse.org/472482 472482] QVTo now integrates with [[JDT]] to resolve blackbox modules on the classpath of a Java project. This makes it possible to get rid of the 'No blackbox implementation found' warning.

[https://bugs.eclipse.org/562175 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.

[https://bugs.eclipse.org/565747 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 <code>@Module(packageURIs={"http://www.eclipse.org/emf/2002/Ecore"})</code>.

[https://bugs.eclipse.org/566216 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.

[https://bugs.eclipse.org/566230 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:

[https://bugs.eclipse.org/573449 573449] It is now possible to resolve blackboxes against dynamic metamodels from the workspace. This is achieved by analyzing the corresponding GenModel.

[https://bugs.eclipse.org/573752 573752] Resolving blackboxes is now possible even if the underlying metamodels are located in required bundles.

Further improvements:

[https://bugs.eclipse.org/573659 573659] QVTo projects are now able to import *.qvto units from required plug-in projects (requires [[PDE]]).

[https://bugs.eclipse.org/570407 570407] QVTo can now handle metamodels that use a relative URI (such as <code>../../org.eclipse.emf.ecore/model/Ecore.ecore</code>) to reference other metamodels. If they are not present in the workspace, the referenced metamodels are searched in the corresponding package registry.

[https://bugs.eclipse.org/566236 566236] Loading *.qvto units in standalone mode is now possible even if the path to a unit contains whitespace.

[https://bugs.eclipse.org/472466 472466] The return type of multiple <code>Sequence</code> operations such as <code>excluding</code> was corrected to <code>Sequence</code> (fixed by [[OCL]]).

=3.10.5 (December 2021)=

This release provides further improvements to the support for blackbox development in the workspace:

[https://bugs.eclipse.org/573449 573449] Blackboxes may now use dynamic metamodels from the workspace.

[https://bugs.eclipse.org/574706 574706] Blackbox class loading and analysis improved.

Further improvements:

[https://bugs.eclipse.org/573718 573718] 'out' parameters are no longer cloned as part of the trace.

[https://bugs.eclipse.org/577310 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==

[https://bugs.eclipse.org/573449 573449] Java blackboxes imported from the workspace now reload correctly when changing the underlying Java implementation.

==3.10.6 Release Candidate 1==

[https://bugs.eclipse.org/571406 571406] The search for Java blackboxes in the workspace now takes less time. To be found, blackboxes need to be imported by the QVTo unit or annotated with [https://download.eclipse.org/mmt/qvto/javadoc/m2m.qvt.oml/3.8.0/org/eclipse/m2m/qvt/oml/blackbox/java/Module.html @Module].

[https://bugs.eclipse.org/577618 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.

[https://bugs.eclipse.org/577992 577992] Blackboxes based on dynamic metamodels can now be imported by a QVTo unit and executed in the workspace.

[https://bugs.eclipse.org/578625 578625] Transformations importing blackboxes from the workspace may be serialized to *.qvtox files.

[https://bugs.eclipse.org/578955 578955] Blackboxes in the workspace may be imported with access or extends.