Home » Archived » EMF-IncQuery » Different Results when usin API in runtime Eclipse and in JUnit Plugin Test
|
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1028549 is a reply to message #1028491] |
Thu, 28 March 2013 11:56   |
 Abel Hegedus
Messages: 197
Registered: September 2015 |
Senior Member |
|
|
Hello Jan,
I'll try to answer to the parts that I can:
1. If you run your test as a Plugin, the EMF-IncQuery injector is automatically prepared and the EPackage registry is filled with registered packages (which includes those you mentioned). Also, creating multiple injectors can cause problems, though I'm not sure that happens here. We run a lot of JUnit plugin tests and it works without additional "registration".
2. If you don't get any matches, it means that (a) your pattern is not available, that can be debugged at the getOrCreateMatcherFactory line, (b) your pattern refers to EClasses that are different from the EClasses actually used by the EObjects in the resource set you match on (c) you are trying to match on EPackages that are in the EPackage registry, but the resource set has no "outgoing" references to EClasses in the registry.
3. You said you "deactivated the run in ui thread", did you also take care to exclude all ui related plugins from your Run Configuration?
4. The Notifier you pass to getMatcher or getEngine is used to specify the scope of pattern matching, if you pass the resource, then EOBjects in other resources in the same resourceSet will not be included in the traversal and pattern matching (see http://incquery.net/incquery/faq#Q:_What_is_included_in_the_query_results_if_the_matcher_is_attached_to_an_EMF_model_root_that_is_not_the_entire_ResourceSet_just_some_Resource_or_containment_subtree)
It would help if we knew what kind of patterns you are trying to match, especially if it involves some exotic cases (EPackage registry contents without actually refering to the EClasses, EIQ pattern models, or similar).
|
|
|
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1038154 is a reply to message #1028549] |
Wed, 10 April 2013 13:25 |
Jan Reimann
Messages: 140
Registered: July 2009 |
Senior Member |
|
|
Hi Abel,
thanks for your answer and sorry for the late reply.
Abel Hegedus wrote:
> 1. If you run your test as a Plugin, the EMF-IncQuery injector is
> automatically prepared and the EPackage registry is filled with
> registered packages (which includes those you mentioned). Also, creating
> multiple injectors can cause problems, though I'm not sure that happens
> here. We run a lot of JUnit plugin tests and it works without additional
> "registration".
Ok, I removed all my registrations. Honestly, they stem from my previous
setup where I tried to run the test in a normal JUnit test.
> 2. If you don't get any matches, it means that (a) your pattern is not
> available, that can be debugged at the getOrCreateMatcherFactory line,
Well, I load my pattern with "normal" EMF means. That means, the pattern
is referenced in another EMF-based model which is loaded on startup.
Thus, I have an EIQ pattern model which is passed to
getOrCreateMatcherFactory. I checked that out, the pattern could be
loaded and contains no unresolved proxies. Do you think it is better to
use getMatcherFactory(String patternPath) in my test setup?
> (b) your pattern refers to EClasses that are different from the EClasses
> actually used by the EObjects in the resource set you match on
My pattern model refers to our Java metamodel JaMoPP (www.jamopp.org).
And the models I want to query are Java "files".
> (c) you
> are trying to match on EPackages that are in the EPackage registry, but
> the resource set has no "outgoing" references to EClasses in the registry.
What dou you mean with this exactly?
> 3. You said you "deactivated the run in ui thread", did you also take
> care to exclude all ui related plugins from your Run Configuration?
To overcome any problems with this I reactivated to run in UI thread.
> 4. The Notifier you pass to getMatcher or getEngine is used to specify
> the scope of pattern matching, if you pass the resource, then EOBjects
> in other resources in the same resourceSet will not be included in the
> traversal and pattern matching (see
> http://incquery.net/incquery/faq#Q:_What_is_included_in_the_query_results_if_the_matcher_is_attached_to_an_EMF_model_root_that_is_not_the_entire_ResourceSet_just_some_Resource_or_containment_subtree)
Thanks for the link.
> It would help if we knew what kind of patterns you are trying to match,
> especially if it involves some exotic cases (EPackage registry contents
> without actually refering to the EClasses, EIQ pattern models, or similar).
I hope I could describe my setup better as mentioned before.
best regards,
Jan
|
|
|
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1038164 is a reply to message #1038154] |
Wed, 10 April 2013 13:41 |
Jan Reimann
Messages: 140
Registered: July 2009 |
Senior Member |
|
|
Abel, I forgot to mention something:
Jan Reimann wrote:
>> 2. If you don't get any matches, it means that (a) your pattern is not
>> available, that can be debugged at the getOrCreateMatcherFactory line,
> Well, I load my pattern with "normal" EMF means. That means, the pattern
> is referenced in another EMF-based model which is loaded on startup.
> Thus, I have an EIQ pattern model which is passed to
> getOrCreateMatcherFactory. I checked that out, the pattern could be
> loaded and contains no unresolved proxies. Do you think it is better to
> use getMatcherFactory(String patternPath) in my test setup?
The current result of getOrCreateMatcherFactory(pattern) is a new
GenericMatcherFactory.
best regards,
Jan
|
|
|
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1039487 is a reply to message #1038164] |
Fri, 12 April 2013 08:12 |
Gabor Bergmann
Messages: 36
Registered: July 2009 |
Member |
|
|
Hi Jan,
I think I have some ideas. I hope I am on the right track, and not wasting your time.
> > (b) your pattern refers to EClasses that are different from the EClasses
> > actually used by the EObjects in the resource set you match on
> My pattern model refers to our Java metamodel JaMoPP (www.jamopp.org).
I suspect that this is the key.
Can we learn some more of your setup?
I presume you have (a) a developer Eclipse, where you develop your JUnit plugin test project, and (b) a launch config that starts a headless Eclipse instance that contains of this test project as one of its constituent plug-ins.
Now the main question is how JaMoPP fits into this picture. For example, if you have JaMoPP source checked out as Java source projects into the workspace of your host Eclipse (a), and you load these as plug-in dependencies into your launch config (b), then you will actually have two ways of accessing your JaMoPP metamodel. It can be accessed (using a workspace resource URI) from the workspace of Eclipse (a), or as a metamodel contributed by plug-in into the EPackage registry of Eclipse (b). These two metamodels, albeit isomorphic, will not be the same.
Is there a chance that this describes your situation? If yes, then we can help you resolve it 
---
> Well, I load my pattern with "normal" EMF means. That means, the pattern
> is referenced in another EMF-based model which is loaded on startup.
> Thus, I have an EIQ pattern model which is passed to
> getOrCreateMatcherFactory. I checked that out, the pattern could be
> loaded and contains no unresolved proxies. Do you think it is better to
> use getMatcherFactory(String patternPath) in my test setup?
Yes, it would be better for a number of reasons. The prerequisite is simply adding your EMF-IncQuery project as a plug-in dependency (if your JUnit plug-in test is in a different project).
By the way, is there a specific reason why go through all the trouble of using the generic matcher API? Did you encounter any trouble with the recommended way, i.e. using the nice user-friendly generated matcher classes with the cool patter-specific API?
Hope that helps,
Gábor
[Updated on: Fri, 12 April 2013 08:12] Report message to a moderator |
|
|
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1039629 is a reply to message #1039487] |
Fri, 12 April 2013 11:31 |
Eclipse User |
|
|
|
Hi Gabor,
thanks for your answer.
Gabor Bergmann wrote:
> I presume you have (a) a developer Eclipse, where you develop your JUnit
> plugin test project, and (b) a launch config that starts a headless
> Eclipse instance that contains of this test project as one of its
> constituent plug-ins.
> Now the main question is how JaMoPP fits into this picture. For example,
> if you have JaMoPP source checked out as Java source projects into the
> workspace of your host Eclipse (a), and you load these as plug-in
> dependencies into your launch config (b), then you will actually have
> two ways of accessing your JaMoPP metamodel. It can be accessed (using a
> workspace resource URI) from the workspace of Eclipse (a), or as a
> metamodel contributed by plug-in into the EPackage registry of Eclipse
> (b). These two metamodels, albeit isomorphic, will not be the same.
>
> Is there a chance that this describes your situation? If yes, then we
> can help you in resolving it :)
No that's not the case. I have a dependency to the installed JaMoPP
metamodel plugin. And since I'm running Eclipse headless JUnit test it
is the same setup as a normal Eclipse runtime. Furthermore, I
implemented a check in my test case:
private void checkMetamodels(Pattern pattern, Resource resource) {
PatternModel patternModel = (PatternModel) pattern.eContainer();
ImportDeclaration importDeclaration =
patternModel.getImportPackages().get(0);
EPackage metamodelPattern = null;
if(importDeclaration instanceof PackageImport){
PackageImport packageImport = (PackageImport) importDeclaration;
metamodelPattern = packageImport.getEPackage();
}
assertNotNull("import must reference an EPackage", importDeclaration);
while(metamodelPattern.getESuperPackage() != null){
metamodelPattern = metamodelPattern.getESuperPackage();
}
EObject model = resource.getContents().get(0);
EPackage metamodelResource = model.eClass().getEPackage();
while(metamodelResource.getESuperPackage() != null){
metamodelResource = metamodelResource.getESuperPackage();
}
assertEquals("metamodels of pattern and resource must be equal",
metamodelPattern, metamodelResource);
}
> Yes, it would be better for a number of reasons. The prerequisite is
> simply adding your EMF-IncQuery project as a plug-in dependency (if your
> JUnit plug-in test is in a different project).
See my next answer.
> By the way, is there a specific reason why go through all the trouble of
> using the generic matcher API? Did you encounter any trouble with the
> recommended way, i.e. using the nice user-friendly generated matcher
> classes with the cool patter-specific API?
I must go the generic way because I cannot make any assumptions about
which pattern is to be queried. In my use case several patterns can be
registered at my extension point which then must be queried.
Furthermore, I deactivated the generation of matcher classes, thus, no
matcher factories are registered either. So I recognized that I cannot
use getMatcherFactory(String patternPath) because it returns null if noc
factory is registered.
best regards,
Jan
|
|
| | | |
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1075321 is a reply to message #1041680] |
Mon, 29 July 2013 08:23 |
Jan Reimann
Messages: 140
Registered: July 2009 |
Senior Member |
|
|
I sent my projects to Istvan, but I assume the setup was to hard. So, I
want to open this discussion again and created a minimal setup that
shows my problem. Find attached my test project and try the following 2
scenarios:
Prerequisite for both:
* install JaMoPP from update site http://jamopp.org/update_trunk
* it's needed to handle Java sources as EMF-based models
1) Runtime Eclipse:
* open the file
src/org/modelrefactoring/incquery/test/query/dataTransmissionWithoutCompression.eiq
* open Query Explorer and press Play
right-click
src/org/modelrefactoring/incquery/test/model/DataTransmissionWithoutCompression.java
and select "Open With -> EMFText java editor"
* press Play in Query Explorer
* you'll find 2 results for the pattern "dataTransmissionWithoutCompression"
2) Headless Eclipse:
* run the test file
src/org/modelrefactoring/incquery/test/IncQueryHeadlessTest.java as
JUnit Plugin Test
* you'll get no results
It would be very helpful if I get the same results in both scenarios
since I want to get my tests run in the build server.
best regards,
Jan
Istvan Rath wrote:
> Quote:
>> I tried it out and it doesn't change anything. Of course, I get a
>> specific IMatcherFactory now, but I don't get any matching results.
>> Any further ideas?
>>
>> best regards,
>> Jan
>
>
> Hi Jan,
>
> if you send me your code and models, I would be glad to help.
>
> regards,
> Istvan
>
|
|
| | | | | |
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1076414 is a reply to message #1076395] |
Wed, 31 July 2013 11:05 |
Jan Reimann
Messages: 140
Registered: July 2009 |
Senior Member |
|
|
Hi Istvan,
Istvan Rath wrote:
> Sorry, the correct link is
> http://www.eclipse.org/forums/index.php/t/495143/
Ok, Dimitris cannot load his pattern generically. But in my test project
I can. I'll drop him an answer in his thread.
But the main problem there is the checks. I don't have any checks, thus
I assume it's another issue?
> Your testcase programmatically loads an EIQ file (this functionality is
> broken at the moment), and then proceeds to use the first pattern in
> that file as the unit under test. IMHO, this is somewhat risky practice,
> as the order of Pattern instances inside a parsed EIQ model is not
> guaranteed, hence your testcase might or might not test what you
> intended. Instead, it would be better to somehow deterministically
> identify the pattern to test (e.g. by using its name, see
> http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API/Advanced#Initializing_matchers_and_accessing_results
> for an example.
Well Ok, in my real setup I don't just load the first pattern from the
model but identify it by name.
What exactly is broken in the loading mechanism? It works very well for me.
best regards,
Jan
|
|
| |
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1076511 is a reply to message #1076446] |
Wed, 31 July 2013 13:58 |
Jan Reimann
Messages: 140
Registered: July 2009 |
Senior Member |
|
|
Hi Istvan,
Istvan Rath wrote:
> here:
> http://www.eclipse.org/forums/index.php/mv/msg/495143/1076441/#msg_1076441
> I have posted some details that apply to your code as well, in order to
> make it work with recent (post 0.7.0 release) versions of IncQuery.
This doesn't work for me since I cannot find the GeneratorModule which
is instantiated in createInjector() method. Which plugin dependency do I
have to add?
> However, the core issue remains - 0 results in the JUnit test. I would
> like to investigate this further, but for that I'll need your help - can
> you make sure that the contents of the ResultSet that is
> programmatically initialized from your test code is absolutely identical
> to the ResourceSet that is used by the Jamopp editor? (Hint: if you look
> at how it appears inside the Query Explorer, the topmost line indicates
> that there are several external resources loaded next to the main model,
> and I'm not entirely sure that they are present in the JUnit version too.)
I had a look at this. And in my attached test project the resource set
contained only 2 resources: the Java file and the resource belonging to
java.lang.Object. But you are right, the resource set in the
QueryExplorer contains a lot of resources more. Thus, I thought that
maybe the proxies must be resolved. So I changed my initJavaResource()
method to this:
private static void initJavaResource() {
JaMoPPUtil.initialize();
File file = new
File("src/org/modelrefactoring/incquery/test/model/DataTransmissionWithoutCompression.java");
assertTrue("File must exist", file != null && file.exists());
javaResource = JavaResourceUtil.getResource(file);
JavaResourceUtil.resolveAll(javaResource);
assertNotNull("Java resource " + file.getAbsolutePath() + " couldn't be
loaded", javaResource);
}
That way the resource set contains more resources but not all being
contained in the QueryExplorer resource set. Ok, I try to find this out.
But what exactly is the problem with the resources in the resource set?
Shouldn't IncQuery throw an exception if the model to be parsed contains
unresolved elements?
best regards,
Jan
|
|
|
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1076624 is a reply to message #1076511] |
Wed, 31 July 2013 16:58 |
Istvan Rath
Messages: 59
Registered: July 2009 |
Member |
|
|
Hi Jan,
Quote:This doesn't work for me since I cannot find the GeneratorModule which
is instantiated in createInjector() method. Which plugin dependency do I
have to add?
org.eclipse.incquery.tooling.core, I have added a remark on this to http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API/Advanced#Loading_EIQ_resources_programmatically
Quote:But what exactly is the problem with the resources in the resource set?
Shouldn't IncQuery throw an exception if the model to be parsed contains
unresolved elements?
Exceptions are thrown only if your queries attempt to "navigate across" unresolvable elements.
I don't know how Jamopp resources work, but I guess your patterns assume that EObjects representing Java types "external" to the current compilaton unit (i.e. "FileBody" in your example) are automagically added by some mechanism to the resource set. I don't know how this mechanism, and the cross-referencing works, but I guess it must be triggered somehow explicitly (maybe by taking the classpath of the project that your Java file is located in into account - at least that is how it works with Xtext, see the other forum thread I referenced previously).
Anyway, if we could make somehow make sure that the ResourceSets in the editor and in your test environment are absolutely identical, then this would greatly help in isolating the location of the error (if there is any).
best regards,
Istvan
|
|
|
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1076666 is a reply to message #1076624] |
Wed, 31 July 2013 18:13 |
Gabor Bergmann
Messages: 36
Registered: July 2009 |
Member |
|
|
Istvan Rath wrote on Wed, 31 July 2013 18:58Hi Jan,
Quote:
Shouldn't IncQuery throw an exception if the model to be parsed contains
unresolved elements?
Exceptions are thrown only if your queries attempt to "navigate across" unresolvable elements.
Minor clarification 1: such model traversal errors do not emerge as exceptions, but are logged instead to the log4j logger of IncQuery engine.
Minor clarification 2: sometimes unresolvable references just mean that we have to wait until they become resolvable, so IIRC no errors are thrown at all in this case.
[Updated on: Wed, 31 July 2013 18:13] Report message to a moderator |
|
|
| Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1077050 is a reply to message #1076624] |
Thu, 01 August 2013 07:22 |
Jan Reimann
Messages: 140
Registered: July 2009 |
Senior Member |
|
|
Hi Istvan,
Istvan Rath wrote:
> org.eclipse.incquery.tooling.core, I have added a remark on this to
> http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API/Advanced#Loading_EIQ_resources_programmatically
thanks
>> But what exactly is the problem with the resources in the resource set?
>> Shouldn't IncQuery throw an exception if the model to be parsed contains
>> unresolved elements?
>
>
> Exceptions are thrown only if your queries attempt to "navigate across"
> unresolvable elements.
> I don't know how Jamopp resources work, but I guess your patterns assume
> that EObjects representing Java types "external" to the current
> compilaton unit (i.e. "FileBody" in your example) are automagically
> added by some mechanism to the resource set. I don't know how this
> mechanism, and the cross-referencing works, but I guess it must be
> triggered somehow explicitly (maybe by taking the classpath of the
> project that your Java file is located in into account - at least that
> is how it works with Xtext, see the other forum thread I referenced
> previously).
Yes, JaMoPP does it the same way. But it seems that it only loads the
referenced classes imported of the Java file and not the whole classpath
as it is done in a Eclipse setup but not in a test setup. I'll dig into it.
> Anyway, if we could make somehow make sure that the ResourceSets in the
> editor and in your test environment are absolutely identical, then this
> would greatly help in isolating the location of the error (if there is
> any).
I'm on my way ;)
best regards,
Jan
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 00:09:50 GMT 2024
Powered by FUDForum. Page generated in 0.02913 seconds |
] 
Search
Help
Register
Login
Home
