Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "MMT/QVTo/New and Noteworthy/2019-09"

< MMT
m
m
Line 29: Line 29:
 
[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/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] Transformation containers are now automatically registered in the plugin.xml file when creating a new QVTo plugin project.
+
[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/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.
+
[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.
+
[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.

Revision as of 04:56, 11 March 2021

3.10.0

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

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

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

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.

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

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.

Back to the top