Difference between revisions of "EMFIncQuery/Releases/MigrateTo0.7"

From Eclipsepedia

Jump to: navigation, search
(Databinding plug-in)
 
(17 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Architecture changes ==
+
Original article: http://incquery.net/incquery/documentation/newandnoteworthy/migrate-0.7
  
=== New component: incquery.evm plug-in ===
+
== Architecture changes  ==
  
New trigger engine component to develop event-driven applications.
+
=== New component: incquery.evm plug-in ===
   
+
The existing integration frameworks validation.runtime and databinding.runtime now depends on this new plug-in.
+
  
=== Renamed all projects ===
+
New trigger engine component to develop event-driven applications. For a more detailed description of the EVM component, see [http://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/EventDrivenVM EventDrivenVM].
All projects have been renamed to be present in the <nowiki>org.eclipse.incquery</nowiki> namespace. A table showing the new and old names is created for a brief overview.
+
 
 +
The existing integration frameworks validation.runtime and databinding.runtime now depend on this new plug-in.
 +
 
 +
=== New component: EMF-IncQuery Viewers ===
 +
 
 +
The Viewers framework provides a generic way to fill lists, tree and graph viewer components with the results of selected queries. For a more detailed description, see [[EMFIncQuery/UserDocumentation/IncQuery_Viewers]].
 +
 
 +
=== Renamed all projects ===
 +
 
 +
All projects have been renamed to be present in the <nowiki>org.eclipse.incquery</nowiki> namespace. A table showing the new and old names is created for a brief overview.  
  
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
! Old name
+
! Old name  
! New name
+
! New name  
 
! Remarks
 
! Remarks
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.databinding.runtime
+
| org.eclipse.viatra2.emf.incquery.databinding.runtime  
| org.eclipse.incquery.databinding.runtime
+
| org.eclipse.incquery.databinding.runtime  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.tooling.generator.databinding
+
| org.eclipse.viatra2.emf.incquery.tooling.generator.databinding  
| org.eclipse.incquery.databinding.tooling
+
| org.eclipse.incquery.databinding.tooling  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.patternlanguage.emf
+
| org.eclipse.viatra2.patternlanguage.emf  
| org.eclipse.incquery.patternlanguage.emf
+
| org.eclipse.incquery.patternlanguage.emf  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.patternlanguage.emf.ui
+
| org.eclipse.viatra2.patternlanguage.emf.ui  
| org.eclipse.incquery.patternlanguage.emf.ui
+
| org.eclipse.incquery.patternlanguage.emf.ui  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.patternlanguage.generator.util
+
| org.eclipse.viatra2.patternlanguage.generator.util  
| org.eclipse.incquery.patternlanguage.generator
+
| org.eclipse.incquery.patternlanguage.generator  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.patternlanguage.core
+
| org.eclipse.viatra2.patternlanguage.core  
| org.eclipse.incquery.patternlanguage
+
| org.eclipse.incquery.patternlanguage  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.patternlanguage.core.ui
+
| org.eclipse.viatra2.patternlanguage.core.ui  
| org.eclipse.incquery.patternlanguage.ui
+
| org.eclipse.incquery.patternlanguage.ui  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.derived
+
| org.eclipse.viatra2.emf.incquery.derived  
| org.eclipse.incquery.querybasedfeatures.runtime
+
| org.eclipse.incquery.querybasedfeatures.runtime  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.tooling.generator.derived
+
| org.eclipse.viatra2.emf.incquery.tooling.generator.derived  
| org.eclipse.incquery.querybasedfeatures.tooling
+
| org.eclipse.incquery.querybasedfeatures.tooling  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.base.itc
+
| org.eclipse.viatra2.emf.incquery.base.itc  
| org.eclipse.incquery.runtime.base.itc
+
| org.eclipse.incquery.runtime.base.itc  
 
|  
 
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.base
+
| org.eclipse.viatra2.emf.incquery.base  
| org.eclipse.incquery.runtime.base
+
| org.eclipse.incquery.runtime.base  
 
|  
 
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.runtime.gmf
+
| org.eclipse.viatra2.emf.incquery.runtime.gmf  
| rowspan="2"| org.eclipse.incquery.runtime.gmf
+
| rowspan="2" | org.eclipse.incquery.runtime.gmf  
| rowspan="2"| Restructured GMF specific code
+
| rowspan="2" | Restructured GMF specific code
 
|-
 
|-
 
| org.eclipse.viatra2.emf.incquery.validation.runtime.ui.gmf
 
| org.eclipse.viatra2.emf.incquery.validation.runtime.ui.gmf
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.runtime.graphiti
+
| org.eclipse.viatra2.emf.incquery.runtime.graphiti  
| org.eclipse.incquery.runtime.graphiti
+
| org.eclipse.incquery.runtime.graphiti  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.gtasm.patternmatcher.incremental.rete
+
| org.eclipse.viatra2.gtasm.patternmatcher.incremental.rete  
| org.eclipse.incquery.runtime.rete
+
| org.eclipse.incquery.runtime.rete  
 
| Version number downgrade to 0.7.0 to match other projects
 
| Version number downgrade to 0.7.0 to match other projects
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.runtime
+
| org.eclipse.viatra2.emf.incquery.runtime  
| org.eclipse.incquery.runtime
+
| org.eclipse.incquery.runtime  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.tooling.core
+
| org.eclipse.viatra2.emf.incquery.tooling.core  
| rowspan="2" | org.eclipse.incquery.tooling.core
+
| rowspan="2" | org.eclipse.incquery.tooling.core  
 
| rowspan="2" | Merging two projects
 
| rowspan="2" | Merging two projects
 
|-
 
|-
|org.eclipse.viatra2.emf.incquery.tooling.generator
+
| org.eclipse.viatra2.emf.incquery.tooling.generator
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.tooling.generator.model.ui
+
| org.eclipse.viatra2.emf.incquery.tooling.generator.model.ui  
| org.eclipse.incquery.tooling.generator.model.ui
+
| org.eclipse.incquery.tooling.generator.model.ui  
 
|  
 
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.tooling.generator.model
+
| org.eclipse.viatra2.emf.incquery.tooling.generator.model  
| org.eclipse.incquery.tooling.generator.model
+
| org.eclipse.incquery.tooling.generator.model  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.tooling.generator.ui
+
| org.eclipse.viatra2.emf.incquery.tooling.generator.ui  
| org.eclipse.incquery.tooling.generator.sampleui
+
| org.eclipse.incquery.tooling.generator.sampleui  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.tooling.retevis
+
| org.eclipse.viatra2.emf.incquery.tooling.retevis  
| org.eclipse.incquery.tooling.ui.retevis
+
| org.eclipse.incquery.tooling.ui.retevis  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.tooling.gui
+
| org.eclipse.viatra2.emf.incquery.tooling.gui  
| org.eclipse.incquery.tooling.ui
+
| org.eclipse.incquery.tooling.ui  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.validation.runtime.ui
+
| org.eclipse.viatra2.emf.incquery.validation.runtime.ui  
| org.eclipse.incquery.validation.runtime.ui
+
| org.eclipse.incquery.validation.runtime.ui  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.validation.runtime
+
| org.eclipse.viatra2.emf.incquery.validation.runtime  
| org.eclipse.incquery.validation.runtime
+
| org.eclipse.incquery.validation.runtime  
|
+
|  
 
|-
 
|-
| org.eclipse.viatra2.emf.incquery.tooling.generator.validation
+
| org.eclipse.viatra2.emf.incquery.tooling.generator.validation  
| org.eclipse.incquery.validation.tooling
+
| org.eclipse.incquery.validation.tooling  
|
+
|  
 
|}
 
|}
=== 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 two ways to update the existing EMF-IncQuery project:
+
== 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:
 +
###.project snippets for versions [https://gist.github.com/ujhelyiz/4169326#file-old_project.xml]:0.6.x [https://gist.github.com/ujhelyiz/4169326#file-new_project-xml]:0.7 respectively.
 +
###Basically, you have to update the nature and buildcommands registered.
 +
##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 .project file update described in Step 2 automatically, but you still have to clean the plugin.xml file and trigger a full rebuild manually.
 +
 
 +
=== API changes  ===
 +
 
 +
==== 0.7-M2  ====
  
# 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.
+
*Databinding plug-in
# Manually update the existing project:
+
**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.  
## 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:
+
*Query-based Features
### plugin.xml snippets for versions [https://gist.github.com/ujhelyiz/4169326#file-old_project.xml]:0.6.x  [https://gist.github.com/ujhelyiz/4169326#file-new_project-xml]:0.7 respectively.
+
**All corresponding code has been moved to a separate plugin.  
### Basically, you have to update the nature and buildcommands registered.
+
**The handler, helper and corresponding classes have been renamed. This should not cause problems if you regenerate your code.
## Remove all references of generated code from the plugin.xml.
+
**The annotation is changed to @QueryBasedFeature, the old annotation is marked as deprecated.
## Trigger a full rebuild of the project to regenerate all matcher and integration code.
+
*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 <tt>.newEmptyMatch()</tt>.
  
== API changes ==
+
==== 0.7-M3  ====
  
=== Databinding plug-in ===
+
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.
  
* 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.
+
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 [[EMFIncQuery/UserDocumentation/API|Basic API documentation]] and [[EMFIncQuery/UserDocumentation/API/Advanced|Advanced API documentation]].  
  
=== Query-based Features ===
+
Here we briefly overview the most important changes with respect to M2.
  
* All corresponding code has been moved to a separate plugin.
+
*Basic API changes
* The handler, helper and corresponding classes have been renamed. This should not cause problems if you regenerate your code.
+
**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).  
* The annotation is changed to @QueryBasedFeature, the old annotation is marked as deprecated.
+
**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 [[EMFIncQuery/UserDocumentation/API#Loading_an_instance_model_and_executing_a_query|here]] for an example.
 +
**The generated [[EMFIncQuery/UserDocumentation/API#Initialization_of_pattern_groups|pattern group]] renamed from GroupOfFile&lt;&lt;EIQFileName&gt;&gt;.java to &lt;&lt;EIQFileName&gt;&gt;.java.
 +
*Advanced API changes
 +
**''MatcherFactory'' renamed to ''QuerySpecification. QuerySpecification''s 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 ''IncQueryEngine''s 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''' (meaning that it is your responsibility to dispose of it).
 +
****only such ''AdvancedIncQueryEngine''s 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 [[EMFIncQuery/UserDocumentation/API/Advanced#Sample_code|Sample code]] and the [http://eclipse.org/incquery/javadoc/milestones/m3/org/eclipse/incquery/runtime/api/AdvancedIncQueryEngine.html Javadoc]&nbsp;for details.  
 +
*Change processing callbacks are as follows:
 +
**For the basic API, it is recommended to use [[EMFIncQuery/UserDocumentation/API#Tracking_changes_in_match_sets_efficiently|IncQuery Databinding Support]] through ''IncQueryObservables''.
 +
**For the advanced API, [http://eclipse.org/incquery/javadoc/milestones/m3/org/eclipse/incquery/runtime/api/AdvancedIncQueryEngine.html#addModelUpdateListener(org.eclipse.incquery.runtime.api.IncQueryModelUpdateListener) model] and match update listeners are available that can be processed from simple Java code or using the new [[EMFIncQuery/DeveloperDocumentation/EventDrivenVM|Event-driven Virtual Machine]] facility.
  
 
[[Category:EmfIncQuery]]
 
[[Category:EmfIncQuery]]

Latest revision as of 04:38, 1 July 2013

Original article: http://incquery.net/incquery/documentation/newandnoteworthy/migrate-0.7

Contents

[edit] Architecture changes

[edit] New component: incquery.evm plug-in

New trigger engine component to develop event-driven applications. For a more detailed description of the EVM component, see EventDrivenVM.

The existing integration frameworks validation.runtime and databinding.runtime now depend on this new plug-in.

[edit] New component: EMF-IncQuery Viewers

The Viewers framework provides a generic way to fill lists, tree and graph viewer components with the results of selected queries. For a more detailed description, see EMFIncQuery/UserDocumentation/IncQuery_Viewers.

[edit] 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.databinding.runtime org.eclipse.incquery.databinding.runtime
org.eclipse.viatra2.emf.incquery.tooling.generator.databinding org.eclipse.incquery.databinding.tooling
org.eclipse.viatra2.patternlanguage.emf org.eclipse.incquery.patternlanguage.emf
org.eclipse.viatra2.patternlanguage.emf.ui org.eclipse.incquery.patternlanguage.emf.ui
org.eclipse.viatra2.patternlanguage.generator.util org.eclipse.incquery.patternlanguage.generator
org.eclipse.viatra2.patternlanguage.core org.eclipse.incquery.patternlanguage
org.eclipse.viatra2.patternlanguage.core.ui org.eclipse.incquery.patternlanguage.ui
org.eclipse.viatra2.emf.incquery.derived org.eclipse.incquery.querybasedfeatures.runtime
org.eclipse.viatra2.emf.incquery.tooling.generator.derived org.eclipse.incquery.querybasedfeatures.tooling
org.eclipse.viatra2.emf.incquery.base.itc org.eclipse.incquery.runtime.base.itc
org.eclipse.viatra2.emf.incquery.base org.eclipse.incquery.runtime.base
org.eclipse.viatra2.emf.incquery.runtime.gmf org.eclipse.incquery.runtime.gmf Restructured GMF specific code
org.eclipse.viatra2.emf.incquery.validation.runtime.ui.gmf
org.eclipse.viatra2.emf.incquery.runtime.graphiti org.eclipse.incquery.runtime.graphiti
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.runtime org.eclipse.incquery.runtime
org.eclipse.viatra2.emf.incquery.tooling.core org.eclipse.incquery.tooling.core Merging two projects
org.eclipse.viatra2.emf.incquery.tooling.generator
org.eclipse.viatra2.emf.incquery.tooling.generator.model.ui org.eclipse.incquery.tooling.generator.model.ui
org.eclipse.viatra2.emf.incquery.tooling.generator.model org.eclipse.incquery.tooling.generator.model
org.eclipse.viatra2.emf.incquery.tooling.generator.ui org.eclipse.incquery.tooling.generator.sampleui
org.eclipse.viatra2.emf.incquery.tooling.retevis org.eclipse.incquery.tooling.ui.retevis
org.eclipse.viatra2.emf.incquery.tooling.gui org.eclipse.incquery.tooling.ui
org.eclipse.viatra2.emf.incquery.validation.runtime.ui org.eclipse.incquery.validation.runtime.ui
org.eclipse.viatra2.emf.incquery.validation.runtime org.eclipse.incquery.validation.runtime
org.eclipse.viatra2.emf.incquery.tooling.generator.validation org.eclipse.incquery.validation.tooling

[edit] Migrating Your Projects

[edit] 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:

  1. 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.
  2. Manually update the existing project:
    1. 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:
      1. .project snippets for versions [1]:0.6.x [2]:0.7 respectively.
      2. Basically, you have to update the nature and buildcommands registered.
    2. Remove all references of generated code from the plugin.xml.
    3. Trigger a full rebuild of the project to regenerate all matcher and integration code.
  3. 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 .project file update described in Step 2 automatically, but you still have to clean the plugin.xml file and trigger a full rebuild manually.

[edit] API changes

[edit] 0.7-M2

  • 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().

[edit] 0.7-M3

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 (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: