Community
Participate
Working Groups
We must adapt the query mechanism for the new eFacet2 metamodel.
I committed a first implementation with one unit test in revision 1050. I'm leaving this open for now because there are more unit tests that need to be written.
In org.eclipse.emf.facet.util.emf.core.internal.catalog.CatalogSetManager.getBundleByResource(Resource), if the parameter is null an IllegalArgumentException should be thrown. And this as to be documented.
In revision 1094 I refactored IQueryEvaluator to IDerivedTypedElementEvaluator : * the methods in IDerivedTypedElementEvaluator take DerivedTypedElements instead of Queries * The "queryEvaluatorRegistration2" extension point becomes "derivedTypedElementEvaluatorRegistration". * "IQueryManager" becomes "IDerivedTypedElementManager" * Query*Exception become DerivedTypedElement*Exception * IQuery2EvaluatorFactory becomes IDerivedTypedElementEvaluatorFactory.java - IDerivedTypedElementManager * added typed (and type-checked) versions of the APIs * added APIs to evaluate on several sources at once I have added unit tests for the IDerivedTypedElementEvaluator in revision 1096. In revision 1097, I have handled the case where a query is not defined in a bundle, and CatalogSetManager#getBundleByResource now throws an exception if its parameter is null.
In revision 1098 I implemented multiple evaluation: I added IDerivedTypedElementCollectionEvaluator, a sub-interface of IDerivedTypedElementEvaluator. The implementor of an evaluator can choose to implement this interface to optimize query evaluation on multiple source elements at once. Otherwise, the framework performs the multiple evaluation by calling the single evaluation multiple times. I added many tests for IDerivedTypedElementManager, and I fixed the bugs I discovered through the tests.
In revision 1099, I handled exceptions in the evaluation of derived typed elements, and I added unit tests that check the behaviors with exceptions. I'm marking this bug as fixed.
In revision 1124, I refactored "IDerivedTypedElementEvaluator" to "IDerivedTypedElementImplementation" (and the associated factory, extension point, existing usages, etc.). And I added a "setValue" method in the interface in order to be able to implement in the future the planned feature to set the value of a derived typed element through a query. Since there is implementation for this at the moment, I'm reopening this bug.
I've a warning on a line committed in revision 1094 : QueryImpl extends non-API type DocumentedElementImpl QueryImpl.java /org.eclipse.emf.facet.efacet2.metamodel/src/org/eclipse/emf/facet/efacet2/metamodel/efacet/extensible/impl line 53 API Usage Problem
I've improved an error message in org.eclipse.emf.facet.query.java.core.internal.evaluator.JavaQueryDerivedTypedElementImplementationFactory. Committed revision 1158.
I’ve fixed the warning described in Comment 7 by removing an inheritance between Query and DocumentElement. This inheritance was false and was causing the warning. Committed revision 1166.
The declaration of Query has been updated. (cf. Comment 9) The dummyQuery meta-model and the javaQuery meta-model have then to be updated. Committed revision 1168. Committed revision 1169.
Something gets wrong in the last update of efacet2.genmodel (dependencies to Ecore disappeared). I Fixed that and I disabled all warnings on the project org.eclipse.emf.facet.facet2.metamodel. Committed revision 1174.
The API of the plug-in org.eclipse.emf.facet.query.java.core use types provided by the API of the plug-ins org.eclipse.emf.facet.efacet.core. I've then mark as reexported the used plug-in must be reexported. Committed revision 1181.
I deprecated the following (not yet released) public interfaces as part of Bug 376941: - org.eclipse.emf.facet.efacet.core.query.IDerivedTypedElementCollectionImplementation - org.eclipse.emf.facet.efacet.core.query.IDerivedTypedElementImplementation - org.eclipse.emf.facet.efacet.core.query.IDerivedTypedElementImplementationFactory
(In reply to comment #6) > And I added a "setValue" method in the interface in order to be able to > implement in the future the planned feature to set the value of a derived typed > element through a query. > > Since there is implementation for this at the moment, I'm reopening this bug. The "setValue" subject is tracked by the bug 365726. We can then close this bug.
