From Eclipsepedia

Jump to: navigation, search


EMF-IncQuery Builder

Builder Refactor in EMF-IncQuery 0.8


  • Remove globaleiqmodel.xmi from IncQuery projects
    • Helps removing Eclipse/OSGi dependencies from runtime
  • Create a programmable API for query definitions
    • The code generator can target this
  • Enhance builder performance (hopefully)

Query API Refactor

Members of query API:

* PSystem (from runtime.rete project)
* Match, Matcher, QuerySpecification, MatchProcessor (from runtime project)

The API needs to be available from the patternlanguage.emf project (where the JvmModelInferrer must be placed) -> a dependency in runtime from patternlanguage.emf needs to be broken

Possible solutions:

  1. Merge runtime project and patternlanguage.emf project
    • Pro: simple implementation
    • Con: runtime will have a lot of Xtext dependencies
  2. Create a base runtime api project, and patternlanguage.emf depends on this
    • Pro: clean architecture
    • Con: API compatibility: classes should change from package (problematic for Match, Matcher interfaces...)
  3. Invert dependency between runtime and patternlanguage.emf, and introduce a patternlanguage/Xtext-specific API bundle (e.g. with Xbase interpreter and API to create query specifications from Patterns)
    • Pro: runtime API may remain largely unchanged; clean architecture
    • Con: requires very careful implementation; new dependency required for existing users


  1. No more getOrCreateQuerySpecification method in QuerySpecificationRegistry, as runtime has no knowledge about constructing query specifications anymore.
    • Affected by: components that try to load and manage query specifications generically (e.g. Query Explorer and derived features in core).
    • Workaround: create a specification using SpecificationBuilder, and load it into the registry as needed