Community
Participate
Working Groups
Currently the QueryEnvironmen() constructor builds its own EPackageProvider in the constructor : /** * Creates a new {@link QueryEvaluationEngine} instance. * * @param crossReferencer * a new {@link CrossReferencer} that will be used to resolve eReference requests in services * needed it. */ public QueryEnvironment(CrossReferenceProvider crossReferencer) { ePackageProvider = new EPackageProvider(); lookupEngine = new BasicLookupEngine(crossReferencer); this.initStandardServices(); this.logger = Logger.getLogger(this.getClass().getName()); } having the hability to pass my own EPackageProvider would allow me to handle the lifecycle and the "where to find the EPackages", being in the current resourceSet or somewhere else. That's a reponsability for the implementer of the EPackageProvider. Also the Method QueryEnvironment.registerEPackage(EPackage) is directly delegating to the EPackageProvider and should probably not belong to QueryEnvironment at all once the EPackageProvider can be created and handled by the calling code.
It belong to the QueryEnvironment because all data from outside should be centralized in the QueryEnvironment. The look up of an EPackage/EClass must be the same at compilation/validation/evaluation time, so changes on EPacakges registration must be explicit. At some point we would probably introduce a QueryEnvironment listener to react to service registration, EPackage registration, and probably variable type changes. So EPackageProvider should not be API.
I'm quite convinced. We should deal with this at the Sirius level, making sure we can provide AQL a list of Ecore models to consider (and maybe enforcing it in the .odesign as a first step) and we might fall back to "registering all the known metamodels" otherwise.
We all agree on this point. So I close it.
