Metamodels of the IncQuery
37 views
Skip to first unread message
Emre Taspolatoglu
May 27, 2013, 6:54:14 AM5/27/13
to incquer...@googlegroups.com
Hello again!
I have a few questions regarding the meta-models "PatternLanguage" and "EMFPatternLanguage" from the IncQuery.
I was looking into the globalEiqModel.xmi of any IncQuery-Project. What I have seen was, that this globalEiqModel.xmi should be an instance of the PatternLanguage.ecore. But there are few model parts such as "ClassType" as a child of "Variable", "EClassifierConstraint" as a child of "PatternBody" or "PackageImport" as a direct child of the "PatternModel". If I am not mistaken, these model components are coming from another meta-model, and this is "EMFPatternLanguage".
I have looked into the metamodels, but I couldn't manage to find any connection between these two models. PatternLanguage.ecore has somehow no reference to the EMFPatternLanguage.ecore. Or I am reviewing the whole thing somehow wrong.
Since I am trying to use some self created pattern model XMI's with the AdvancedQueryAPI, I created a dynamic instance of the PatternLanguage.ecore. But that was also not successful, since the model parts from EMFPatternLanguage.ecore couldn't be created as a part of the dynamic instance.
So, I would be very glad, if you could point me into the right direction regarding these problems. I need to be able to create an instance of the Pattern Model as an XMI file to use with the AdvancedQueryAPI.
Thanks a lot!
Emre
I have a few questions regarding the meta-models "PatternLanguage" and "EMFPatternLanguage" from the IncQuery.
I was looking into the globalEiqModel.xmi of any IncQuery-Project. What I have seen was, that this globalEiqModel.xmi should be an instance of the PatternLanguage.ecore. But there are few model parts such as "ClassType" as a child of "Variable", "EClassifierConstraint" as a child of "PatternBody" or "PackageImport" as a direct child of the "PatternModel". If I am not mistaken, these model components are coming from another meta-model, and this is "EMFPatternLanguage".
I have looked into the metamodels, but I couldn't manage to find any connection between these two models. PatternLanguage.ecore has somehow no reference to the EMFPatternLanguage.ecore. Or I am reviewing the whole thing somehow wrong.
Since I am trying to use some self created pattern model XMI's with the AdvancedQueryAPI, I created a dynamic instance of the PatternLanguage.ecore. But that was also not successful, since the model parts from EMFPatternLanguage.ecore couldn't be created as a part of the dynamic instance.
So, I would be very glad, if you could point me into the right direction regarding these problems. I need to be able to create an instance of the Pattern Model as an XMI file to use with the AdvancedQueryAPI.
Thanks a lot!
Emre
Zoltán Ujhelyi
May 27, 2013, 4:43:07 PM5/27/13
to incquer...@googlegroups.com
Hi, Emre,
you are right about the elements of the "EMFPatternLanguage" metamodel not available from the "PatternLanguage" metamodel in any direct way (including dynamic package imports). This is mainly caused by the fact that the metamodels (and the corresponding grammars) were developed in a way to separate the elements that are EMF-dependent (e.g. the way to describe types, or EEnum literals) from other, structured elements, such as patterns, constraints, etc. The main goal with this was to be able to re-use as much of this new language as possible in other modeling domains, e.g. the VPM metamodel employed by VIATRA2 project (see http://eclipse.org/viatra2) or RDF models.
In this sense, the models described by the globaleiqmodel.xmi are not instances of the "PatternLanguage" metamodel but the "EMFPatternLanguage" metamodel, that allow using elements from both metamodels. If you want to create such models programmatically, you have to use factories for both model elements, and start your model with a PatternModel instance of the type defined in EMFPatternLanguage.
I hope, this solution is understandable, if not, feel free to ask for clarification.
Cheers,
Zoltán
you are right about the elements of the "EMFPatternLanguage" metamodel not available from the "PatternLanguage" metamodel in any direct way (including dynamic package imports). This is mainly caused by the fact that the metamodels (and the corresponding grammars) were developed in a way to separate the elements that are EMF-dependent (e.g. the way to describe types, or EEnum literals) from other, structured elements, such as patterns, constraints, etc. The main goal with this was to be able to re-use as much of this new language as possible in other modeling domains, e.g. the VPM metamodel employed by VIATRA2 project (see http://eclipse.org/viatra2) or RDF models.
In this sense, the models described by the globaleiqmodel.xmi are not instances of the "PatternLanguage" metamodel but the "EMFPatternLanguage" metamodel, that allow using elements from both metamodels. If you want to create such models programmatically, you have to use factories for both model elements, and start your model with a PatternModel instance of the type defined in EMFPatternLanguage.
I hope, this solution is understandable, if not, feel free to ask for clarification.
Cheers,
Zoltán
Emre Taspolatoglu
May 27, 2013, 5:16:28 PM5/27/13
to incquer...@googlegroups.com
Hi Zoltan,
thanks a lot for the quick response. And yes, indeed that was what I needed to find out. I have tried what you sad, created a dynamic instance of the PatternModel from the EMFPatternLanguage.ecore, which is actually inherited from the PatternModel of PatternLanguage.ecore. And now I can also create these constructs missing in my first approach, such as "Class Types" or "Package Imports".
And again, you were right, I am trying to programmatically create valid .xmi-files (like globalEiqModel.xmi), which can be searched for query patterns by the Advanced IncQuery API and be executed on EMF-models. I believe that this should be possible, since what Advanced API only need is the globalEiqModel.xmi of a IncQuery project, and not the *.eiq-file of it. Do you have any tips or some points where I should especially pay more attention?
Best regards,
Emre
thanks a lot for the quick response. And yes, indeed that was what I needed to find out. I have tried what you sad, created a dynamic instance of the PatternModel from the EMFPatternLanguage.ecore, which is actually inherited from the PatternModel of PatternLanguage.ecore. And now I can also create these constructs missing in my first approach, such as "Class Types" or "Package Imports".
And again, you were right, I am trying to programmatically create valid .xmi-files (like globalEiqModel.xmi), which can be searched for query patterns by the Advanced IncQuery API and be executed on EMF-models. I believe that this should be possible, since what Advanced API only need is the globalEiqModel.xmi of a IncQuery project, and not the *.eiq-file of it. Do you have any tips or some points where I should especially pay more attention?
Best regards,
Emre
Istvan Rath
May 28, 2013, 1:34:34 AM5/28/13
to EMF-IncQuery Users on behalf of Emre Taspolatoglu
Hi Emre,
And again, you were right, I am trying to programmatically create valid .xmi-files (like globalEiqModel.xmi), which can be searched for query patterns by the Advanced IncQuery API and be executed on EMF-models.
We have this feature (i.e. dynamic queries) on our development agenda as well. We were brainstorming about several alternative approaches:
1) provide an easy-to-use (light-weight) helper API to make the programmatic construction of EMFPatternModel instances easier
2) develop a way so that the programmers can provide a String (containing a valid pattern language construct) as a query to be evaluated (e.g. similarly to traditional JDBC)
3) develop a dedicated Java API that maps the constructs of the IncQuery pattern language to Java classes/methods directly (as a "heavier" alternative to 1)
Which option would you prefer as a user?
(Btw. these are all alternatives for the future, after we are done with the 0.7 release.)
Regards,
Istvan
Emre Taspolatoglu
May 28, 2013, 5:07:31 AM5/28/13
to incquer...@googlegroups.com
Hello Istvan,
the alternatives sound all well, but for the reasons of easy development support, I would rather use the first approach. Also, the second one seems very interesting, since the use of straight-forward String sequences, can attract programmers, which are not especially willing to APIs in their projects.
But, as a part of my project, I need to be able use manually-created *.xmi-files (from EMFPatternLanguage.ecore :)), which have of course valid query patterns, and execute them through the Advanced IncQuery API. After youy response about having such dynamic queries on your agenda, I created a dynamic instance of EMFPatternLanguage.ecore manually and created a valid query pattern in it by following a globalEiqModel.xmi from one of my test projects. The result of the AdvancedAPI was unfortunately negativ. The Advanced API was able to extract the pattern from the manually created xmi-file, but didn't get any results after that.
As far as I can see, the only difference between the generated globalEiqModel.xmi and the manually created xmi-file is, that all the patterns in the generated one are backed up with corresponding IncQuery-Project, and this can be seen as the "FileName" attribute in every pattern. Of course in my manually created xmi-file, this field is empty.
After all that struggle, I was wondering if my approach is even possible for the time being? I thought, that since only globalEiqModel.xmi's are needed for the AdvancedAPI, any xmi-file could be queried for patterns, and if the found ones are valid, can also be executed on EMF models. If this is indeed possible, could you please point me out where I might be doing something wrong?
Your help will be really appreciated.
Best regards,
Emre
the alternatives sound all well, but for the reasons of easy development support, I would rather use the first approach. Also, the second one seems very interesting, since the use of straight-forward String sequences, can attract programmers, which are not especially willing to APIs in their projects.
But, as a part of my project, I need to be able use manually-created *.xmi-files (from EMFPatternLanguage.ecore :)), which have of course valid query patterns, and execute them through the Advanced IncQuery API. After youy response about having such dynamic queries on your agenda, I created a dynamic instance of EMFPatternLanguage.ecore manually and created a valid query pattern in it by following a globalEiqModel.xmi from one of my test projects. The result of the AdvancedAPI was unfortunately negativ. The Advanced API was able to extract the pattern from the manually created xmi-file, but didn't get any results after that.
As far as I can see, the only difference between the generated globalEiqModel.xmi and the manually created xmi-file is, that all the patterns in the generated one are backed up with corresponding IncQuery-Project, and this can be seen as the "FileName" attribute in every pattern. Of course in my manually created xmi-file, this field is empty.
After all that struggle, I was wondering if my approach is even possible for the time being? I thought, that since only globalEiqModel.xmi's are needed for the AdvancedAPI, any xmi-file could be queried for patterns, and if the found ones are valid, can also be executed on EMF models. If this is indeed possible, could you please point me out where I might be doing something wrong?
Your help will be really appreciated.
Best regards,
Emre
Istvan Rath
May 28, 2013, 5:12:18 AM5/28/13
to EMF-IncQuery Users on behalf of Emre Taspolatoglu
Hi Emre,
The result of the AdvancedAPI was unfortunately negativ. The Advanced API was able to extract the pattern from the manually created xmi-file, but didn't get any results after that.
After all that struggle, I was wondering if my approach is even possible for the time being? I thought, that since only globalEiqModel.xmi's are needed for the AdvancedAPI, any xmi-file could be queried for patterns, and if the found ones are valid, can also be executed on EMF models. If this is indeed possible, could you please point me out where I might be doing something wrong?
The usecase you are trying should work, we just haven't tested it yet (extensively). I can help you, but for that I need a sample project that you are trying to get to work (including queries, any code, and example instance models).
Regards
Istvan
Emre Taspolatoglu
May 28, 2013, 6:48:04 AM5/28/13
to incquer...@googlegroups.com
Hello Istvan,
thanks for the quick reply.
Well, it is good to know, that this is possible. But for now, I -unfortunately- don't have a simple sample project, which I can send you, it's because the to be queried sample models are quite big and complicated. But If I would have the time, I would create such a tiny project just for test purposes, so I can send you this.
In the mean time, I have managed to go a few steps further by debugging etc. The AdvancedAPI can find the patterns in my manually created xmi-file, but these are not forwarded to the IMatcherFactory, so the IncQueryMatcher can't process them.
So in the following code, after extraction of the as parameter given pattern, "if(factory!=null) { ... } fails and gives no results. Eventually the engine will be wiped at the end of the whole execution.
if (p!=null) {
try {
factory = MatcherFactoryRegistry.getMatcherFactory(p);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println("Pattern found!");
} else {
// Fall back to the registry in case the pattern model extraction didn't work
factory = MatcherFactoryRegistry.getMatcherFactory(queryPattern);
System.err.println("Pattern NOT found!");
}
try {
if (factory!=null) {
System.out.println("Factory NOT empty!");
try {
IncQueryMatcher<? extends IPatternMatch> matcher = factory.getMatcher(engine);
Collection<? extends IPatternMatch> matches = matcher.getAllMatches();
prettyPrintMatches(results, matches);
} catch (Exception e) {
System.err.println("Execution failed!");
e.printStackTrace();
}
} else {
System.err.println("What is wrong with the factory?!");
}
} catch (Exception e) {
e.printStackTrace();
}
the error "What is wrong with the factory?!" is printed out. With some further logging help, I have also seen, that the pattern extracted with the given parameter from the manually created xmi-file look like this:
org.eclipse.incquery.patternlanguage.patternLanguage.impl.PatternImpl@21bab424 (name: stakeholders, fileName: null)
Again, fileName is missing because there is no IncQuery-project backing this up. Beside the file name, the patterns in the manually created xmi-file are totally the same from one globalEiqModel.xmi, which is from another test project and which works fine with my same application that uses AdvancedAPI.
Only one difference comes to my mind. I had to load/import the needed model resources also manually to dynamic instance of the emfPatternLanguage.ecore and had to point "Package Import" manually to ones I needed to use. By the generated globalEiqModel.xmi they are imported automatically, since the corresponding *.eiq-file from its project imports them. Don't know, if this makes a difference.
Hope you could help me further. And please say if anything wasn't clear enough.
Again thanks and best regards,
Emre
thanks for the quick reply.
Well, it is good to know, that this is possible. But for now, I -unfortunately- don't have a simple sample project, which I can send you, it's because the to be queried sample models are quite big and complicated. But If I would have the time, I would create such a tiny project just for test purposes, so I can send you this.
In the mean time, I have managed to go a few steps further by debugging etc. The AdvancedAPI can find the patterns in my manually created xmi-file, but these are not forwarded to the IMatcherFactory, so the IncQueryMatcher can't process them.
So in the following code, after extraction of the as parameter given pattern, "if(factory!=null) { ... } fails and gives no results. Eventually the engine will be wiped at the end of the whole execution.
if (p!=null) {
try {
factory = MatcherFactoryRegistry.getMatcherFactory(p);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println("Pattern found!");
} else {
// Fall back to the registry in case the pattern model extraction didn't work
factory = MatcherFactoryRegistry.getMatcherFactory(queryPattern);
System.err.println("Pattern NOT found!");
}
try {
if (factory!=null) {
System.out.println("Factory NOT empty!");
try {
IncQueryMatcher<? extends IPatternMatch> matcher = factory.getMatcher(engine);
Collection<? extends IPatternMatch> matches = matcher.getAllMatches();
prettyPrintMatches(results, matches);
} catch (Exception e) {
System.err.println("Execution failed!");
e.printStackTrace();
}
} else {
System.err.println("What is wrong with the factory?!");
}
} catch (Exception e) {
e.printStackTrace();
}
the error "What is wrong with the factory?!" is printed out. With some further logging help, I have also seen, that the pattern extracted with the given parameter from the manually created xmi-file look like this:
org.eclipse.incquery.patternlanguage.patternLanguage.impl.PatternImpl@21bab424 (name: stakeholders, fileName: null)
Again, fileName is missing because there is no IncQuery-project backing this up. Beside the file name, the patterns in the manually created xmi-file are totally the same from one globalEiqModel.xmi, which is from another test project and which works fine with my same application that uses AdvancedAPI.
Only one difference comes to my mind. I had to load/import the needed model resources also manually to dynamic instance of the emfPatternLanguage.ecore and had to point "Package Import" manually to ones I needed to use. By the generated globalEiqModel.xmi they are imported automatically, since the corresponding *.eiq-file from its project imports them. Don't know, if this makes a difference.
Hope you could help me further. And please say if anything wasn't clear enough.
Again thanks and best regards,
Emre
Istvan Rath
May 28, 2013, 8:12:12 AM5/28/13
to EMF-IncQuery Users on behalf of Emre Taspolatoglu
Hi Emre,
as a first suggestion, I recommend you to upgrade to the recently published M3 of EMF-IncQuery, as we have made several improvements to the API which you might benefit from. If you do so, please make sure to read http://wiki.eclipse.org/EMFIncQuery/Releases/MigrateTo0.7#0.7-M3 carefully.
Secondly, I believe that you do not need to make use of MatcherFactories (or, as they are called in the new API, QuerySpecifications) at all. Instead, you should simply use the IncQueryEngine::getMatcher(Pattern) method with a valid Pattern object.
Regards,
Istvan
--
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/msgid/incquery-users/38e455d5-4fdc-414b-8f21-f1cafbfc4f73%40googlegroups.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Emre Taspolatoglu
May 28, 2013, 9:08:12 AM5/28/13
to incquer...@googlegroups.com
Hello Istvan,
as for your suggestion, I would prefer to wait for the migration, at least till I get my project up and running; unless you do think that I have to migrate for what I intend to do.
For your tip about the getMatcher, I will be trying it in a few seconds, I respond accordingly. Hope it works.
By the way, I had downloaded the EMF-IncQuery from your Update Site, and as the Integration Build. Version number is as follow: EMF-IncQuery SDK (Incubation) 0.7.0.201304241314
Isn't that actually the latest build, also the so called M3?
Thanks and best regards,
Emre
as for your suggestion, I would prefer to wait for the migration, at least till I get my project up and running; unless you do think that I have to migrate for what I intend to do.
For your tip about the getMatcher, I will be trying it in a few seconds, I respond accordingly. Hope it works.
By the way, I had downloaded the EMF-IncQuery from your Update Site, and as the Integration Build. Version number is as follow: EMF-IncQuery SDK (Incubation) 0.7.0.201304241314
Isn't that actually the latest build, also the so called M3?
Thanks and best regards,
Emre
Emre Taspolatoglu
May 28, 2013, 9:42:18 AM5/28/13
to incquer...@googlegroups.com
Hello again Istvan,
could you please give me a code sample, using the getMatcher-method of the IncQueryEngine.
I have already instantiated an IncQueryEngine in my code as follows:
IncQueryEngine engine = EngineManager.getInstance().createUnmanagedIncQueryEngine(resource);
resource being here is the sample EMF model to be queried with patterns.
But are no getMatcher methods defined for the IncqueryEngine.
A simple example should be very helpful, thanks.
Best regrads,
Emre
On Monday, May 27, 2013 12:54:14 PM UTC+2, Emre Taspolatoglu wrote:
could you please give me a code sample, using the getMatcher-method of the IncQueryEngine.
I have already instantiated an IncQueryEngine in my code as follows:
IncQueryEngine engine = EngineManager.getInstance().createUnmanagedIncQueryEngine(resource);
resource being here is the sample EMF model to be queried with patterns.
But are no getMatcher methods defined for the IncqueryEngine.
A simple example should be very helpful, thanks.
Best regrads,
Emre
On Monday, May 27, 2013 12:54:14 PM UTC+2, Emre Taspolatoglu wrote:
Istvan Rath
May 28, 2013, 1:33:44 PM5/28/13
to EMF-IncQuery Users on behalf of Emre Taspolatoglu
Hi Emre,
But are no getMatcher methods defined for the IncqueryEngine.
Because we introduced them for M3.
A simple example should be very helpful, thanks.
I have pushed it to Git, you can take a look here:
This code only works with M3 (and more recent integration builds, at least 201305221225 (which is exactly M3, downloadable from http://download.eclipse.org/incquery/updates/milestone/)
Regards
Istvan
Emre Taspolatoglu
May 28, 2013, 2:26:27 PM5/28/13
to incquer...@googlegroups.com
Hello Istvan,
perfect! Indeed the migration to M3 worked for me. I have also reworked my own application. And now I don't get any errors regarding the factories etc.
Now by using the globalEiqModel.xmi of a test project of mine, I get the results pretty printed in the console. Can call all of the patterns from that test IncQuery project.
But when I use a pattern from this manually created PatternModel.xmi of eMFPatternLanguage.ecore (on the same EMF sample model), the result is "Empty match set".
I have also printed out the patterns, we extract using the given parameter. They are as follows:
From valid globalEiqModel.xmi: org.eclipse.incquery.patternlanguage.patternLanguage.impl.PatternImpl@4fa176aa (name: testquery.stakeholders, fileName: platform:/resource/edu.kit.ipd.sdq.incquery/src/testquery/testquery.eiq)
From my own PatternModel.xmi: org.eclipse.incquery.patternlanguage.patternLanguage.impl.PatternImpl@6457242a (name: decisions, fileName: null)
Beside from that, I really can't think of anything. These patterns are identical, from variable references to constraints. Do you have any idea, what the reason might be?
And again, I really appreciate the help you are giving me. Thank you!
Best regards,
Emre
perfect! Indeed the migration to M3 worked for me. I have also reworked my own application. And now I don't get any errors regarding the factories etc.
Now by using the globalEiqModel.xmi of a test project of mine, I get the results pretty printed in the console. Can call all of the patterns from that test IncQuery project.
But when I use a pattern from this manually created PatternModel.xmi of eMFPatternLanguage.ecore (on the same EMF sample model), the result is "Empty match set".
I have also printed out the patterns, we extract using the given parameter. They are as follows:
From valid globalEiqModel.xmi: org.eclipse.incquery.patternlanguage.patternLanguage.impl.PatternImpl@4fa176aa (name: testquery.stakeholders, fileName: platform:/resource/edu.kit.ipd.sdq.incquery/src/testquery/testquery.eiq)
From my own PatternModel.xmi: org.eclipse.incquery.patternlanguage.patternLanguage.impl.PatternImpl@6457242a (name: decisions, fileName: null)
Beside from that, I really can't think of anything. These patterns are identical, from variable references to constraints. Do you have any idea, what the reason might be?
And again, I really appreciate the help you are giving me. Thank you!
Best regards,
Emre
Emre Taspolatoglu
May 28, 2013, 3:24:18 PM5/28/13
to incquer...@googlegroups.com
Hello again Istvan,
I believe I was wrong. The generated globaEiqModel.xmi and my manually created PatternModel.xmi aren't identical after all. A little glimpse to the manually created pattern model with a text editor and I have seen the difference, which was causing the problem. The difference is in the "classname" attirubte of the "ClassType" as follows:
(gen.) globalEiqModel.xmi: href="http://xyz/abc/0.1#//Stakeholder"/ (as the namespace of corresponding imported package)
(man.) PatternModel.xmi: href="../../../plugin/xyz/model/foo.ecore#//Decision" (as hardcoded?)
After manually adding the correct namespace of the needed package, I was able use these patterns from the manually created *.xmi file. :)
Unfortunately, I don't know how I can solve this problem. My main idea was to transform a certain model to the instances of emfPatternLanguage.ecore and use them with the AdvancedAPI. But if I transform these models to emfPatternLanguage or create its dynamic instance, I have to load the packages from the Eclipse Plugin Registry or from the workspace. If I am not mistaken, globalEiqModel.xmi gets these references from the *.eiq-file of its project, where we define them at the beginning.
Do you have any comments or ideas, how a solution or a workaround might look like?
Thanks again!
Emre
I believe I was wrong. The generated globaEiqModel.xmi and my manually created PatternModel.xmi aren't identical after all. A little glimpse to the manually created pattern model with a text editor and I have seen the difference, which was causing the problem. The difference is in the "classname" attirubte of the "ClassType" as follows:
(gen.) globalEiqModel.xmi: href="http://xyz/abc/0.1#//Stakeholder"/ (as the namespace of corresponding imported package)
(man.) PatternModel.xmi: href="../../../plugin/xyz/model/foo.ecore#//Decision" (as hardcoded?)
After manually adding the correct namespace of the needed package, I was able use these patterns from the manually created *.xmi file. :)
Unfortunately, I don't know how I can solve this problem. My main idea was to transform a certain model to the instances of emfPatternLanguage.ecore and use them with the AdvancedAPI. But if I transform these models to emfPatternLanguage or create its dynamic instance, I have to load the packages from the Eclipse Plugin Registry or from the workspace. If I am not mistaken, globalEiqModel.xmi gets these references from the *.eiq-file of its project, where we define them at the beginning.
Do you have any comments or ideas, how a solution or a workaround might look like?
Thanks again!
Emre
Zoltán Ujhelyi
May 28, 2013, 3:24:33 PM5/28/13
to incquer...@googlegroups.com
Hello Emre,
currently the pattern definitions rely on knowing the exact metamodel object instances when creating the pattern. However, if you refer to the same metamodel file two different ways (e.g. the EPackage registry for instance model and once by using a platform:/plugin style URL when creating a pattern definition), you get two different EClasses that the IncQuery engine currently handles differently.
So in other words, I would look at how do you refer to your Ecore metamodel and how does your instance model refer to it, just to make sure, that exactly the same EClass references are used
For the future, we plan to provide better support for dynamic cases (e.g. in https://bugs.eclipse.org/bugs/show_bug.cgi?id=398874), but it is not landed in the codebase.
I hope, this helps,
Zoltán
currently the pattern definitions rely on knowing the exact metamodel object instances when creating the pattern. However, if you refer to the same metamodel file two different ways (e.g. the EPackage registry for instance model and once by using a platform:/plugin style URL when creating a pattern definition), you get two different EClasses that the IncQuery engine currently handles differently.
So in other words, I would look at how do you refer to your Ecore metamodel and how does your instance model refer to it, just to make sure, that exactly the same EClass references are used
For the future, we plan to provide better support for dynamic cases (e.g. in https://bugs.eclipse.org/bugs/show_bug.cgi?id=398874), but it is not landed in the codebase.
I hope, this helps,
Zoltán
Emre Taspolatoglu
May 28, 2013, 3:31:25 PM5/28/13
to incquer...@googlegroups.com
Hello Zoltan,
I believe, what you refer to is exactly, what I found out in the mean time and posted like seconds ago, isn't it? :)
Do you have any ideas about any workaround, for using such dynamic instances at least for now?
Thanks for your comments.
Emre
I believe, what you refer to is exactly, what I found out in the mean time and posted like seconds ago, isn't it? :)
Do you have any ideas about any workaround, for using such dynamic instances at least for now?
Thanks for your comments.
Emre
Istvan Rath
May 28, 2013, 4:02:20 PM5/28/13
to EMF-IncQuery Users on behalf of Emre Taspolatoglu
Hi Emre,
I believe, what you refer to is exactly, what I found out in the mean time and posted like seconds ago, isn't it? :)
Almost. Zoltan has pointed out the main rule of thumb for correct operation:
1) either both your Pattern model (globalEiqModel.xmi) and your instance model use dynamic instances (whose support is not ready yet in Git -master, but its incorporation is planned for M4)
2) or both your Pattern model and your instance model refer to the types of the metamodel "statically" (i.e. through registered/genmodel-resolvable package URIs) (this is what our tooling assumes at the moment)
For now, you just have to make sure that you generate your pattern model (.xmi) according to option 2). I haven't personally tried doing this yet, but my guess would be that it involves a) the programmatic registration of your ecore in the registry and 2) instantiating your types from the registry. Note that this is more related to EMF in general and not a problem specific to IncQuery.
Do you have any ideas about any workaround, for using such dynamic instances at least for now?
After we merge the support for matching against dynamic instances into Git -master, we'll create an integration build and you'll be able to test whether it solves your problem. Note that we are also planning an upgrade to Xtext 2.4 shortly, I hope this will not break your project.
Regards
Istvan
Emre Taspolatoglu
May 28, 2013, 4:13:55 PM5/28/13
to incquer...@googlegroups.com
Hi Istvan,
I believe I see the problem now. I will try to take my time to solve this issue, only hope that works.
But your next build/version, which will be supporting the dynamic instances, might be little late for me, since the deadline of my project is reaching its end. For further changes I will have to talk to my supervisor, but I believe I will still be making use of your IncQuery in some different way.
Still, hope you keep up the good work. You are doing an amazing thing here. Good luck!
Thanks again and best regards!
Emre
P.S: I might coming back again for different issues. Hope you will again find the time to help. :)
I believe I see the problem now. I will try to take my time to solve this issue, only hope that works.
But your next build/version, which will be supporting the dynamic instances, might be little late for me, since the deadline of my project is reaching its end. For further changes I will have to talk to my supervisor, but I believe I will still be making use of your IncQuery in some different way.
Still, hope you keep up the good work. You are doing an amazing thing here. Good luck!
Thanks again and best regards!
Emre
P.S: I might coming back again for different issues. Hope you will again find the time to help. :)
Istvan Rath
May 28, 2013, 4:26:35 PM5/28/13
to EMF-IncQuery Users on behalf of Emre Taspolatoglu
Hi Emre,
I believe I see the problem now. I will try to take my time to solve this issue, only hope that works.
If you manage to generate your Pattern model with "static" type references, then everything should work just fine.
(Or, use a quick-and-dirty hack, and programmatically correct the references with search-and-replace before loading your Pattern model. :-)
But your next build/version, which will be supporting the dynamic instances, might be little late for me, since the deadline of my project is reaching its end.
Just for reference: the integration build I was referring to can be expected for early next week.
P.S: I might coming back again for different issues. Hope you will again find the time to help. :)
We are always glad to help. Next time please use the Eclipse.org forums for IncQuery, we are shutting down this mailing list shortly so that our support efforts can be even more focused.
Cheers
Istvan
Emre Taspolatoglu
May 28, 2013, 5:09:19 PM5/28/13
to incquer...@googlegroups.com
Hello Istvan,
I will take a look into your suggested workarounds.
And yes, I will be posting any further questions to the new forum. Just to be sure, will you be migrating the posts in this group to the forum somehow? Since there are some pretty helpful informations for me, which I might look for in the future, too.
Best regards,
Emre
I will take a look into your suggested workarounds.
And yes, I will be posting any further questions to the new forum. Just to be sure, will you be migrating the posts in this group to the forum somehow? Since there are some pretty helpful informations for me, which I might look for in the future, too.
Best regards,
Emre
Reply all
Reply to author
Forward
0 new messages