Original article: http://incquery.net/incquery/documentation/newandnoteworthy/migrate-0.7
New component: incquery.evm plug-in
New trigger engine component to develop event-driven applications.
The existing integration frameworks validation.runtime and databinding.runtime now depends on this new plug-in.
Renamed all projects
All projects have been renamed to be present in the org.eclipse.incquery namespace. A table showing the new and old names is created for a brief overview.
|Old name||New name||Remarks|
|org.eclipse.viatra2.emf.incquery.runtime.gmf||org.eclipse.incquery.runtime.gmf||Restructured GMF specific code|
|org.eclipse.viatra2.gtasm.patternmatcher.incremental.rete||org.eclipse.incquery.runtime.rete||Version number downgrade to 0.7.0 to match other projects|
|org.eclipse.viatra2.emf.incquery.tooling.core||org.eclipse.incquery.tooling.core||Merging two projects|
Migrating Your Projects
Changes to Generated Code
As the generated code of EMF-IncQuery depends on the EMF-IncQuery runtime, the renaming of the projects cause the generated projects not working. However, we made sure that all the pattern definitions should work in the new release as well. There are three ways to update the existing EMF-IncQuery project:
- Create a new EMF-IncQuery project using the project wizard, and copy the eiq and eiqgen files and possibly any other manually written file to the new project. Matcher (and integration) code is regenerated, and the project will be ready to use.
- Manually update the existing project:
- Open the .project file of the project, and update the nature and builder references. An example for the rewriting is available in the following GitHub Gist:
- Remove all references of generated code from the plugin.xml.
- Trigger a full rebuild of the project to regenerate all matcher and integration code.
- Starting with M3, you can also use the "Update/Add EMF-IncQuery Nature" menu item from the "Configuration" sub-menu on any project (available through right clicking on the project in the Project Explorer view). This performs the procedure described in Step 2 automatically.
- Databinding plug-in
- The ObservablePattenMatchList class has been extended with a generic type parameter. Additonally, a new factory method is availabe (similar to other databinding factories). See the class IncQueryObservables for details.
- Query-based Features
- All corresponding code has been moved to a separate plugin.
- The handler, helper and corresponding classes have been renamed. This should not cause problems if you regenerate your code.
- The annotation is changed to @QueryBasedFeature, the old annotation is marked as deprecated.
- Matcher / match API changes
- Some methods dealing with array-based match representations (raw*, arrayToMatch, etc.) were removed from the public matcher interface, as they were no longer needed in the vast majority of use cases.
- Matches can now be either mutable or immutable. For safety reasons, the matchers always produce immutable matches; setting their fields will raise an exception. However, matchers do accept a mutable partial match as query input; for setting up such a partial match, you can request a mutable match instance from the matcher by .newEmptyMatch().
The primary goal of M3 was to finalize the public API for the 0.7 release, hence no further API changes are expected until 0.7 is reached.
Starting from 0.7-M3, we have separated the EMF-IncQuery API into two layers: the Basic API includes features that cater to the most common use-cases, while, in addition, the Advanced API also includes more advanced features (such as the ability for custom lifecycle management and change tracking) that are meant only for advanced use-cases.The up-to-date API documentation with illustrative examples is found in Basic API documentation and Advanced API documentation.
Here we briefly overview the most important changes with respect to M2.
- Basic API changes
- Restructuring and simplification of generated packages: all generated packages directly correspond to the package declaration inside EIQ files, an additional .util subpackage is generated for utility classes (that are mostly needed for advanced API features).
- Matcher initialization: from now on, it is recommended to use the IncQueryEngine class and initialize it first, using the static IncQueryEngine.on(Notifier scope) method, and then re-use the result for initializing generated matchers (using the static ...Matcher.on(IncQueryEngine engine) method). See here for an example.
- The generated pattern group renamed from GroupOfFile<<EIQFileName>>.java to <<EIQFileName>>.java.
- Advanced API changes
- MatcherFactory renamed to QuerySpecification. QuerySpecifications are mostly useful for accessing queries registered through the extension point, and accessing the EMF Pattern model behind each query (without having to instantiate a Matcher).
- Changes regarding 'unmanaged' vs. 'advanced' engines and lifecycle changes. In short:
- all IncQueryEngines are managed by default (which means they are disposed automatically once the model is released), and they cannot be disposed manually
- advanced API features are only available if you instantiate an AdvancedIncQueryEngine through AdvancedIncQueryEngine.createUnmanagedEngine(resource);, which will be unmanaged by default (meaning that it is your responsibility to dispose of it).
- only such AdvancedIncQueryEngines support lifecycle operations such as wipe() or dispose()
- the AdvancedIncQueryEngine.from(IncQueryEngine engine) method can be used to turn a managed IncQueryEngine into a managed IncQueryEngine, but this is only for very special purposes and should be used with caution.
- See the Sample code and the Javadoc for details.
- Change processing callbacks are as follows:
- For the basic API, it is recommended to use IncQuery Databinding Suppport through IncQueryObservables.
- For the advanced API, model and org.eclipse.incquery.runtime.api.IMatchUpdateListener, boolean) match update listeners are available that can be processed from simple Java code or using the new Event-driven Virtual Machine facility.