Matcher classes of patterns are not being generated for the further use with PatternMatcher API

21 views
Skip to first unread message

Emre Taspolatoglu

unread,
Apr 25, 2013, 4:42:22 PM4/25/13
to incquer...@googlegroups.com
What could be the reason that the certain patterns from the *.eiq file are not being generated in the src-gen folder as Matchers?

The generated GroupOfFileXXX.java can't resolve the Matcher classes for the patterns from the *.eiq file, since they are simply not being generated. So they also can't be added to the matcherFactories class. Funny thing is, that the packages are for every pattern is simply there, but empty. Furthermore I can run my patternmodel on the example EMF models and get correct results of the queries.

And another thing is, don't know whether it has anything to do with the problem, that only for two of the patterns there are two evaluater classes, which have some check expression based on Xbase.

Thanks!

Emre

Emre Taspolatoglu

unread,
Apr 25, 2013, 5:05:38 PM4/25/13
to incquer...@googlegroups.com
I need to add something, that just came to my attention right now. Very interesting, but at one moment all of the code (Matches, Matchers etc.) were generated, and after while all of them -again- were gone. Except the ones with check constraints. I -unfortunately- have no idea, where this determinism comes from. What could be the reason for that?

Emre Taspolatoglu

unread,
Apr 25, 2013, 5:46:32 PM4/25/13
to incquer...@googlegroups.com
Hello again, some more information to the issue I am having. First of all, I am using a runtime instance of Eclipse, because some of the models I am importing are not registered in the development instance of the Eclipse, but are available in the runtime.

What I have seen so far is, that after a modification of the pattern model (*.eiq) and its save, the corresponding codes are directly generated. But after awhile, all of the generated code is again gone, except the ones with the check constraints. Hope these infos will be more helpful.

Emre


On Thursday, April 25, 2013 10:42:22 PM UTC+2, Emre Taspolatoglu wrote:

Emre Taspolatoglu

unread,
Apr 25, 2013, 6:29:00 PM4/25/13
to incquer...@googlegroups.com
Yet again, some further research, I have found the point that I was missing: http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API#EMF-IncQuery_Java_API

For further development purposes, how should I then configure my Eclipse, so that the generated code will stay permanently?



On Thursday, April 25, 2013 10:42:22 PM UTC+2, Emre Taspolatoglu wrote:

István Ráth

unread,
Apr 26, 2013, 12:47:27 AM4/26/13
to incquer...@googlegroups.com
Hi Emre,


On Friday, 26 April 2013 00:29:00 UTC+2, Emre Taspolatoglu wrote:

For further development purposes, how should I then configure my Eclipse, so that the generated code will stay permanently?


From your descriptions, it appears to me that you have found a bug.

However, it seems to be quite a tricky case, so it would be very helpful if you could provide an incquery project with which this issue can be reproduced. Please fild a bug in the BugZilla and attach this project. We'll look into it ASAP.

cheers
Istvan

Emre Taspolatoglu

unread,
Apr 26, 2013, 4:21:48 AM4/26/13
to incquer...@googlegroups.com
Hello Istvan,

I will look into this as fast as possible and try to provide a project, making this issue reproducible.

Best regards,
Emre

Joost van Pinxten

unread,
Apr 26, 2013, 5:15:03 AM4/26/13
to incquer...@googlegroups.com
This is also something that I have run into; I have however not found a decent way to regenerate the Matchers. Also haven't even been able to reproduce this effect deterministically.

I have also been using the eiq-project containing the pattern files in both the runtime and development Eclipse instance. If I find out something related to this problem (or a reproducable form) I will post it here.

Op vrijdag 26 april 2013 10:21:48 UTC+2 schreef Emre Taspolatoglu het volgende:

Ábel Hegedüs

unread,
Apr 26, 2013, 6:17:26 AM4/26/13
to EMF-IncQuery Users on behalf of Joost van Pinxten
Hello all,

it is a known issue (not only with EMF-IncQuery, but all Eclipse builders) that if you use the same project in the host and runtime, then the same builder can clash with itself.
I have run into the problem with simple Java projects and Xtend classes as well.

Consider the following:
1. You change something in the runtime workspace.
2. The runtime builder starts running to regenerate changed resources.
3. The host workspace realizes that something changed.
4. The host builder starts running and changes the same files as the runtime builder.
5. This race condition may result in partial builds.

Two workarounds for using the same project in the host and the runtime workspace:
- Close the project in the host when running the runtime Eclipse.
- Disable automatic building in the host Eclipse.

Cheers,

--
You received this message because you are subscribed to the Google Groups "EMF-IncQuery Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to incquery-user...@googlegroups.com.
To post to this group, send email to incquer...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/incquery-users/-/4rDaMiL78hcJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Ábel Hegedüs

unread,
Apr 26, 2013, 6:21:00 AM4/26/13
to EMF-IncQuery Users on behalf of Joost van Pinxten
Another suggestion: cleaning the project using the Project -> Clean option should remove everything generated by EMF-IncQuery.
If you disable the automatic rebuilding and call Clean, the project should settle in a state where a new build should be successful (obviously, as long as the new build is not running in both the host and runtime).
Reply all
Reply to author
Forward
0 new messages