Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF-IncQuery » Different Results when usin API in runtime Eclipse and in JUnit Plugin Test
Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1028491] Thu, 28 March 2013 10:18 Go to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
Registered: July 2009
Senior Member
Hello,
I tried to follow the recommendations from Istvan and execute JUnit
Plugin tests for test my functionality w.r.t IncQuery. But unfortunately
I get different results in both setups Eclipse runtime and JUnit Plugin
test. I encapsulate my functionality behind an interface and its single
implementation uses the generic IncQuery API as follows:

EObject model = /** get the model **/ null;
Pattern pattern = /** get the pattern **/ null;
Resource resource = model.eResource();
ResourceSet resourceSet = resource.getResourceSet();
IMatcherFactory<IncQueryMatcher<IPatternMatch>> matcherFactory =
(IMatcherFactory<IncQueryMatcher<IPatternMatch>>)
MatcherFactoryRegistry.getOrCreateMatcherFactory(pattern);
IncQueryMatcher<IPatternMatch> matcher =
matcherFactory.getMatcher(resourceSet);
Collection<IPatternMatch> matches = matcher.getAllMatches();
for (IPatternMatch match : matches) {
// do something with the matches
}

That means in both setups the above implementation is used. Furthermore,
the following initialization is executed to enable loading of a pattern
being referenced in one of my models:

EPackage.Registry.INSTANCE.put(XbasePackage.eNS_URI,
XbasePackage.eINSTANCE);
EPackage.Registry.INSTANCE.put(PatternLanguagePackage.eNS_URI,
PatternLanguagePackage.eINSTANCE);
EPackage.Registry.INSTANCE.put(EMFPatternLanguagePackage.eNS_URI,
EMFPatternLanguagePackage.eINSTANCE);
Injector injector = Guice.createInjector(new
EMFPatternLanguageRuntimeModule());
IResourceFactory resourceFactory =
injector.getInstance(IResourceFactory.class);
Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put("eiq",
resourceFactory);

Now the strange thing is that matcher.getAllMatches() returns the
expected results in the runtime Eclipse setup but in the JUnit Plugin
test setup the result always is empty. In the JUnit Plugin test setup I
deactivated "Run in UI thread" and left all the other options in their
defaults.
Do you have an idea what goes wrong here?

Another observation I'm curious about is that I don't get any matches in
the runtime Eclipse setup when matcherFactory.getMatcher(resource) is
invoked instead of passing the whole resourceSet. Why is that? What is
the difference?

best regards,
Jan
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 Go to previous messageGo to next message
Abel Hegedus is currently offline Abel HegedusFriend
Messages: 105
Registered: July 2009
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 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
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 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
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 Go to previous messageGo to next message
Gabor Bergmann is currently offline Gabor BergmannFriend
Messages: 21
Registered: July 2009
Junior 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 Smile

---

> 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 Go to previous messageGo to next message
Eclipse UserFriend
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 #1039680 is a reply to message #1039629] Fri, 12 April 2013 12:54 Go to previous messageGo to next message
Gabor Bergmann is currently offline Gabor BergmannFriend
Messages: 21
Registered: July 2009
Junior Member
Hi,

> I must go the generic way because I cannot make any assumptions about
which pattern is to be queried

OK, then you clearly need the generic interface.

Still, I would like you to try generating the matcher factory and using getMatcherFactory(String patternPath), at least as a quick experiment.
This is because "generated" patterns contributed by query plug-ins are slightly changed from the original Pattern object parsed from the eiq, to compensate for some EMF-specific magic (including XBase parsing and URI resolving) that may manifest as a difference between the two Eclipse environments (a) and (b).

Does this quick experiment change anything?

Cheers,
Gábor
Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1041552 is a reply to message #1039680] Mon, 15 April 2013 08:36 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
Registered: July 2009
Senior Member
Hi Gabor,

Gabor Bergmann wrote:
> OK, then you clearly need the generic interface.
> Still, I would like you to try generating the matcher factory and using
> getMatcherFactory(String patternPath), at least as a quick experiment.
> This is because "generated" patterns contributed by query plug-ins are
> slightly changed from the original Pattern object parsed from the eiq,
> to compensate for some EMF-specific magic (including XBase parsing and
> URI resolving) that may manifest as a difference between the two Eclipse
> environments (a) and (b).
> Does this quick experiment change anything?
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
Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1041680 is a reply to message #1028491] Mon, 15 April 2013 12:08 Go to previous messageGo to next message
Istvan Rath is currently offline Istvan RathFriend
Messages: 54
Registered: July 2009
Member
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 #1075321 is a reply to message #1041680] Mon, 29 July 2013 08:23 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
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 #1075331 is a reply to message #1075321] Mon, 29 July 2013 08:53 Go to previous messageGo to next message
Istvan Rath is currently offline Istvan RathFriend
Messages: 54
Registered: July 2009
Member
Hi Jan,

Quote:
I sent my projects to Istvan, but I assume the setup was to hard.


did you send them by email? (I never received anything.)

Anyway, I"ll take a look and see what's going wrong.

[Updated on: Mon, 29 July 2013 08:53]

Report message to a moderator

Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1075397 is a reply to message #1075331] Mon, 29 July 2013 10:56 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
Registered: July 2009
Senior Member
Hi Istvan,
I checked it again and found out that I sent it to
forums-noreply@xxxxxxxx ;) So, sorry for that, you never could have
got something.
Thank you for having a look at my project.

best regards,
Jan

Istvan Rath wrote:
> Hi Jan,
>
> Quote:
>> I sent my projects to Istvan, but I assume the setup was to hard.
>
>
> did you send them by email? (I never receiver anything.)
>
> Anyway, I"ll take a look and see what's going wrong.
>
Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1076111 is a reply to message #1075397] Tue, 30 July 2013 18:21 Go to previous messageGo to next message
Istvan Rath is currently offline Istvan RathFriend
Messages: 54
Registered: July 2009
Member
Hi Jan,

I have looked into your project. It seems you have bumped into the same (or very similar) issue as http://www.eclipse.org/forums/index.php/m/1075365.

Until we find a fix (we are working on it now), I recommend you to use the generated API in your tests instead of the generic one.

Istvan
Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1076348 is a reply to message #1076111] Wed, 31 July 2013 08:13 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
Registered: July 2009
Senior Member
Hi Istvan,
thanks for your help! But I don't really udnerstand your link since it
is about GMF 3D?

I cannot use the generated API because I don't know the pattern which is
executed. Furthermore I deactivated the generation of pattern APIs. The
test project I sent to you just nailed down the problem.

best regards,
Jan

Istvan Rath wrote:
> Hi Jan,
>
> I have looked into your project. It seems you have bumped into the same
> (or very similar) issue as
> http://www.eclipse.org/forums/index.php/m/1075365.
>
> Until we find a fix (we are working on it now), I recommend you to use
> the generated API in your tests instead of the generic one.
>
> Istvan
icon1.gif  Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1076395 is a reply to message #1076348] Wed, 31 July 2013 10:13 Go to previous messageGo to next message
Istvan Rath is currently offline Istvan RathFriend
Messages: 54
Registered: July 2009
Member
Quote:
thanks for your help! But I don't really udnerstand your link since it
is about GMF 3D?


Sorry, the correct link is http://www.eclipse.org/forums/index.php/t/495143/


Quote:
I cannot use the generated API because I don't know the pattern which is
executed.


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.

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 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
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 #1076446 is a reply to message #1076395] Wed, 31 July 2013 12:08 Go to previous messageGo to next message
Istvan Rath is currently offline Istvan RathFriend
Messages: 54
Registered: July 2009
Member
Hi Jan,

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.

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.)

Thanks,
Istvan
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 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
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 Go to previous messageGo to next message
Istvan Rath is currently offline Istvan RathFriend
Messages: 54
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 Go to previous messageGo to next message
Gabor Bergmann is currently offline Gabor BergmannFriend
Messages: 21
Registered: July 2009
Junior Member
Istvan Rath wrote on Wed, 31 July 2013 18:58
Hi 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 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
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
Re: Different Results when usin API in runtime Eclipse and in JUnit Plugin Test [message #1082273 is a reply to message #1076624] Thu, 08 August 2013 10:27 Go to previous message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 127
Registered: July 2009
Senior Member
Hi Istvan,
I got it to work :) Thanks for pushing me in the right direction so that
the ResourceSets must be equal. Now I added the standard libraries to
the Java ResourceSet and get the expected results :)

Thanks a lot for your patience!

best regards,
Jan
Previous Topic:Error executing EValidator
Next Topic:[Solved] [EMF-IncQuery Project Builder] : Errors running builder 'EMF-IncQuery Project Builder'
Goto Forum:
  


Current Time: Sat Dec 20 16:00:50 GMT 2014

Powered by FUDForum. Page generated in 0.02713 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software