VIATRA/Query/DeveloperDocumentation/Builder
Contents
EMF-IncQuery Builder
Builder Refactor in EMF-IncQuery 0.8
Goals:
- 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:
- Merge runtime project and patternlanguage.emf project
- Pro: simple implementation
- Con: runtime will have a lot of Xtext dependencies
- 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...)
- 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
Casualties
- 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