Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incquery-dev] incquery & xcore integration

Hi,

first of all, sorry for messing up the build. Since the class that uses the pattern registry in the query-based feature runtime is not used yet, I think we should remove the class from the release (since Xcore integration is also not planned).

As for the pattern registry, it replicates the _query specification registry_ functionality (load query specifications from extension points) and allows additional patterns to be registered.

However, I think it is still not ready for release, for example patterns are registered paired with an IFile, which is on the one hand an extra deoendency on the o.e.core.resources bundle and on the other hand problematic in case of programmatically prepared patterns.

Also, as seen from Zoltán's letter, no core components use it yet.

Ábel

What is the "official" status of the Pattern Registry? Is it now a part of the system, does it replicate Query Explorer functionality, which components depend on it? Is it going to be part of the release?

(These are somewhat open questions that will need to be discussed tomorrow.)

Istvan

--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group

On Monday, June 24, 2013 at 9:29 AM, Ujhelyi Zoltán wrote:

Hi,

the pattern registry feature was only available in the extra update site, so your change have provided a not installable solution from the main update site. As a quick fix, I have added the pattern registry feature (without its GUI that is more or less incomplete) to the SDK feature.

Cheers,
Zoli
-- Zoltán Ujhelyi

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2013.06.22., at 23:18, Ábel Hegedüs <abel.hegedus@xxxxxxxxxx> wrote:

Hi,

I have pushed the new version to the repository.

Also, I have created a small example of what I think is needed to setup the delegates in dynamic mode:

Hope that helps you to progress. Note that I have not tested neither the setting delegate nor the factory or the setup code.

If this approach works, we could change the generator in a way that it doesn't have to touch the generated code, only the Ecore model (to setup the annotations).


Best regards,
Ábel Hegedüs

Fault Tolerant Systems Research Group
Department of Measurement and Information Systems
Budapest University of Technology and Economics
On 2013.06.21. 23:06:03, Ábel Hegedüs <abel.hegedus@xxxxxxxxxx> wrote:
Hi,

almost, it can be used if the query specification is registered in the QuerySpecficiationRegistry which is by default the extensions but can be added programmatically as well.

I have an idea on how to do it without relying on the QuerySpecificationRegistry, but I will not bore everyone with details. In short, the delegatefactory will manage the engines and the patterns and provide the delegates to EMF, Xcore will have to setup the factory with the patterns when the dynamic EPackage is needed.

Cheers,
Ábel Hegedüs

Fault Tolerant Systems Research Group
Department of Measurement and Information Systems
Budapest University of Technology and Economics
On 2013.06.21. 17:53:34, Tamas Szabo <tamas.szabo@xxxxxxxxx> wrote:
Hi

I have one note here: the code that you have pushed can only be used if the query specifications are registered in a plugin.xml (appropriate extension point) right?

Maybe the best would be to attend one of you meetings, but I will discuss this with Istvan.

Regards,
Tamas

Hi,

Separation to two projects:
- In the existing version of query-based features, I have solved that issue by simply not adding the incquery project as a dependency to the model project. Instead, the required query specification was retrieved from the QuerySpecificationRegistry by it's fully qualified name. While you can also use this approach, you will have to make sure that the queries are registered into the QuerySpecificationRegisrty of the running Eclipse. Since the registry only allows adding and not replacing, a better approach would be to use a pattern registry for the dynamic case.
- But, as Zoltán has pointed out, separating the two projects would introduce several new problems for the one that it might solve.

Evaluator code in the dynamic case:
- From a quick look at setting delegates (http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Support_for_Feature_Setting_Delegates [http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Support_for_Feature_Setting_Delegates] show me some more up to date content if you can) I think we just have to create a QueryBasedFeatureSettingDelegate and it's factory and use that in the same way as it is used for Xcore. Instead of parsing an Xcore _expression_, it will the QueryBasedFeatureHandler and retreive the value for the given source. Once initialized, the handler will keep the value of the feature updated and send notifications.
- I have pushed a QueryBasedFeatureSettingDelegate and its Factory to the repository. As I don't fully know how setting delegates work, it may not be correct. However, it should give you a way to register the factory either through annotations or manually in the dynamic case and after that EMF will hopefully just call it as it does other delegates. As before, I would like to see some more documentation on the lifecycle and working of delegates, since that may include information that would impact the implementation of this delegate.

Cheers,
Ábel Hegedüs
_______________________________________________
incquery-dev mailing list

_______________________________________________
incquery-dev mailing list


_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/incquery-dev

Back to the top