Home » Archived » EMF-IncQuery » Another "Ambiguous variable type defintions" problem
| Another "Ambiguous variable type defintions" problem [message #1330113] |
Sat, 03 May 2014 13:29  |
 Emre T
Messages: 119
Registered: April 2013 |
Senior Member |
|
|
Hello again,
really hope, that I am not bothering you all with endless questions. 
I have encountered again an "Ambiguous variable type defintions" problem, but this time with a slightly different background. The scenario is like following.
An abstract SuperClass has a String attribute "name". There are three further sub classes inheriting from it; Sub1, Sub2, Sub3.
Another class, lets say MainClass, references SuperClass as a mutli-cardinal containment ("contains"). So it can contain any of the sub classes with different "name" attribute coming from the abstract SuperClass.
I have implemented a pattern to get to this "name" attribute, but I am only interested in traversing to only one of the sub classes, like Sub2. It looks like the following:
pattern getSub2 (mainClass: MainClass, sub2: Sub2) {
MainClass.contains(mainClass, sub2);
}
pattern getNameOfSub2(sub2: Sub2, name: EString) {
Sub2.name(sub2, name);
}
These patterns are meant to used later in query-based feature patterns, but before coming to his, I get the following error, with which I was confronted before with another configuration, again regarding the inheritance.
Ambiguous variable type defintions: [SuperClass, Sub2],
type cannot be selected. Please specify the one to be used as
the parameter type by adding it to the parameter definition.
The first time I was able to workaround the problem with repeating or-clauses, though it was a different case where the subclasses were the sources of the incremental query, in which I have used the super class as the source parameter and in the pattern body used the subclasses as the beginning of the traversal. But this time it is not the case, this time the values of the references can be the different subclasses and the beginning of the traversal is always the MainClass which is referencing/ containing them.
Funny thing is, that I have exactly the same configuration in my query definition file, where I traverse over an abstract class via the reference of the source to the two different containments. Though the referenced model is different, but it works, and the above is not. So I am thinking of how I import the model URIs or genmodel's maybe a problem?
Do you have any idea, where I might be missing here this time? Maybe a workaround to achieve what I am trying? Or do you need more information to be able to say anything?
Thanks a lot again!
Emre
[Updated on: Sat, 03 May 2014 19:05] Report message to a moderator |
|
|
| Re: Another "Ambiguous variable type defintions" problem [message #1330602 is a reply to message #1330113] |
Sat, 03 May 2014 19:09  |
Emre T
Messages: 119
Registered: April 2013 |
Senior Member |
|
|
Ops, maybe the not exactly configuration. In the definition where such a scenario works is the reference directly in the source element defined, and in this case the reference "contains" of the MainClass comes from an inheritance, so the MainClass inherits the "contains" reference from another model element, e.g. Commentable.
Edit: Ok I have just tried it the other way. That the "contains" reference is directly defined in the MainClass, instead of being inherited from its super class. But the error remains. Funny, that in one case it works, but in another not.
Edit 2: Also an extra information that might be helpful. In the same configuration, if I try to get the abstract SuperClass with a pattern like below I get the following error too:
pattern getSuperClass(mainClass: MainClass, superClass: SuperClass) {
MainClass.contains(mainClass, superClass);
}
Variable has a type which has multiple definitions: [SuperClass]
I believe that these two errors are some how related in this scenario. Also to mention, that this is pretty complicated group of pattern definitions, in which I import like 10 models, which also have cross-references to each other. And this model of SuperClass, Sub1, Sub2, Sub3 (it is a separate package) is referenced by at least two of the imported models, which are used in my definition file at the same time.
Sorry again for the long posts, hope you could help me.
[Updated on: Sat, 03 May 2014 19:34] Report message to a moderator |
|
| |
| Re: Another "Ambiguous variable type defintions" problem [message #1331958 is a reply to message #1331563] |
Sun, 04 May 2014 11:07 |
Emre T
Messages: 119
Registered: April 2013 |
Senior Member |
|
|
Hi Abel, thanks for the input.
When you say as an extension, do you mean the dependencies in manifest? Or simply imports in the definition file?
This package containing the abstract SuperClass and its subclasses Sub1, Sub2, Sub3 is a special metamodel used by almost every other metamodel being imported in my definition file. But until now I didn't have to use any of its model elements directly. So I needed it to be imported as well to access it.
And I think here begins the problem. Because I have already imported other metamodels which are referencing it in their metamodels and genmodels, but I also have to import it now directly in the definition, otherwise no access is possible.
Also its plugin project had to be added as dependency, like for every other metamodel imports as well.
Would you be able to give any tips how to workaround this? Or will it make any differences to add dependencies from plugin platform or from the workspace? Maybe using the .eiqgen will help? (Though I am still not sure how it really works )
Also opening this IncQuery project in runtime instance of Eclipse resolve the mentioned errors, but it is still not built because of some further Xtext error about not being able to get to some imported packages (which are OK in the development environment). I also don't think it wouldn't solve the problem entirely since I need the derived queries generated into my models and the generated pattern code in the IncQuery project.
[Updated on: Sun, 04 May 2014 11:08] Report message to a moderator |
|
|
| Re: Another "Ambiguous variable type defintions" problem [message #1331994 is a reply to message #1331958] |
Sun, 04 May 2014 11:33 |
Abel Hegedus
Messages: 197
Registered: September 2015 |
Senior Member |
|
|
By "extension", I mean the generated_package extensions in the plugin.xml of the project where the generated code of the metamodel is.
Problems may occur, if you have metamodel A, which has a generated_package extension in it's project, then you have metamodel B that refers to metamodel A in a specific way:
- assuming you use regular EMF, open the B.ecore as a text file and check how elements of A are stored, you will either see: "nsURIofA#/typeA" or "../somepath/A.ecore#/typeA" (it may not be completely precise, but you can see the difference).
- if relative file paths are used, then when you import B, it will load B.ecore and since it depends on A.ecore, that is loaded as well (we will call this A1). However, since A is also used, A.ecore is loaded again (through the extension, let's call this A2).
- the Java objects representing elements of B refer to Java objects in A1, however, you also define queries over elements of A, which may use Java objects in A2. The type inferrer will then choke on the different Java objects and through cryptic errors.
In addition, similar problems can occur if you create B.genmodel and don't refer to A.genmodel. In this case, both A.genmodel and B.genmodel will try to provide package A, that can cause further issues.
Using the eiqgen is needed if the generated_package extensions are missing.
Since I have no idea how your different metamodels are distributed to projects and how many genmodels you use, I can not tell which problem you face.
If you can "obfuscate" your ecore, genmodel and plugin.xml files in a way that we can take a look at the important references, we may be able to help you more.
It's important that while you may only see EMF-IncQuery issues at this point, _IF_ some EMF misconfiguration lies in the background, you might run into very cryptic errors later on even if you are not using EMF-IncQuery at all. In this way, the idiot-proof approach of the type inferrer in EMF-IncQuery can sometimes uncover such problems early on.
|
|
|
| Re: Another "Ambiguous variable type defintions" problem [message #1334750 is a reply to message #1331994] |
Mon, 05 May 2014 18:43 |
Emre T
Messages: 119
Registered: April 2013 |
Senior Member |
|
|
Hello Abel,
i was able to follow your tips and indeed seems it to be the problem.
- The referenced models (as your example the "A") are always and in every case referenced through relative paths and not nsURIs.
- All models reside in their own projects.
- All the models are generated already, so they all have their generated_package "extensions". And no referenced model is generated for a second time with the referencing model (Where you choose in genmodel -> Reload)
- Also all the models being used in my pattern definitions are residing in workspace for further adjustments and improvements.
I am really not so sure how I can "obfuscate" the project I am working on. It is actually a big one with a lot of dependencies and tools in the backend. Especially since the models are real models of languages such as Java. But I would try to do so, if I have the time, since it would be an important milestone for me to solve this problem.
Until so, I would like try to depict the scenario one more time as simplified as possible:
There 5 models, all with generated model code and residing in same workspace as the IncQuery project. These models are Java, JavaExtended and JavaExtendedTwo (like their names they indeed extension of a Java in a way) and Props and Common. Which one references which are like the following:
Common (references nothing)
Java -references-> Common
JavaExtended -references-> Java
JavaExtendedTwo -references-> Java
Props -references-> Common
Like mentioned above, all the referenced models (Common and Java) are referenced via relative paths. Also in generator models no referenced ecore model is generated along but referenced.
The imports in my query definition file looks like this:
import //my own models etc.
import "http://www.eclipse.org/emf/2002/Ecore"
import "http://www.eclipse.org/xtext/common/JavaVMTypes"
import "http://www.eclipse.org/xtext/xbase/Xbase"
import "http://java"
import "http://common"
import "http://javaExtended"
import "http://javaExtendedTwo"
import "http://props"
And not using any eiqgen's. The thing is until I tried to integrate the the model Props, eveything was OK. So just importing Java, JavaExtended, JavaExtendedTwo and Common was fine. I was able to traverse their elements and define patterns based on them. Then the derived references were also generated.
So than I tried to create an empty IncQuery project just for this one model resultin in errors: Props
The imports look like this:
import //my own models etc.
import "http://www.eclipse.org/emf/2002/Ecore"
import "http://www.eclipse.org/xtext/common/JavaVMTypes"
import "http://www.eclipse.org/xtext/xbase/Xbase"
import "http://props"
import "http://common"
The same patterns have resulted in the same errors: Ambiguous types and variable definitions. So it leaves to the point that the problem is in the how Props is modeled or how it intervenes with the Common.
But what I have noticed is, that these imports are being added as dependency to the plugin.xml of the IncQuery project in different ways.
Java -> from Workspace (the plugin icon with a orange circle)
JavaExtended and ExtendedTwo -> also from the workspace (again with the circle in the icon)
Common -> Not so sure (with "01" on the plugin icon, what I think has something to do with the importing the plugin into workspace as a binary project)
Props -> Also not sure, same with the "01"
So my next step would be to try a new IncQuery project in a brand new clean workspace just with Props and Common to see, whether the derived queries over them would work on my own models.
But still every tip and help will be appreciated. Hope the information above is not confusing and boring.
Thanks again and best regards,
Emre
P.S.: An extra question, can I have two different IncQuery projects on the same main model for its derived queries? I mean would it be problematic to let two different definition files from two different projects (even from two different workspaces?!) generate the derived features of the model (as long as different derived features are being handled by only one of the projects)?
[Updated on: Mon, 05 May 2014 18:48] Report message to a moderator |
|
| | |
| Re: Another "Ambiguous variable type defintions" problem [message #1336458 is a reply to message #1336256] |
Tue, 06 May 2014 11:59 |
Emre T
Messages: 119
Registered: April 2013 |
Senior Member |
|
|
Hello again Abel,
so I was able to experiment a little bit more with the whole setup.
- First of all, I have checked out all the metamodels (their plugin projects) of these languages from the code repository of the tool being used into my workspace, instead of importing them from my own plugin registry. So these different types of plugin dependencies (with "01" etc.) were gone. There are now either via workspace or via plugin registry. All the necessary models I am working on were being referenced from the workspace, except the trivial ones such as Ecore etc.
- Again, I have created a new project for only this Props and Common models. Where I have not used any of the other models, to ignore any possible circular dependencies.
And still, I am getting the same error:
Ambiguous variable type defintions: [SuperClass, Sub2], type cannot be selected. Please specify the one to be used as the parameter type by adding it to the parameter definition.
For the following definition:
pattern getSub2 (mainClass: MainClass, sub2: Sub2) {
MainClass.contains(mainClass, sub2);
}
I have also eliminated the case entirely, that the reason for this might be the abstract SuperClass, since I was able to use the same pattern definition in my working IncQuery project for Java model, like this:
pattern getSub2ForJavaMainClass (javaClass: JavaClass, sub2: Sub2) {
JavaClass.contains(javaClass, sub2);
}
Where JavaClass also inherits the reference "contains" from a superclass. And this works.
So I'm thinking strongly, that this might not have anything directly how IncQuery works in the backend, but how this Props and Common models are intervening together. Because Common works with other models Java and Extended/ExtendedTwo well.
I must have look further into these models.
|
|
|
| Re: Another "Ambiguous variable type defintions" problem [message #1338551 is a reply to message #1336458] |
Wed, 07 May 2014 09:07 |
Emre T
Messages: 119
Registered: April 2013 |
Senior Member |
|
|
Hi again, some recent news..
My last resort was to open a whole new workspace, in which I have worked without the models (Java, Extended and ExtendedTwo, which were alright). So there are now no complex dependencies, where two different models reference the Common model etc. Also the workspace and the plugin registry are clean of these Java models.
I have implemented a simple metamodel with only one well-behaeving derived reference, that references an element from the Props model. And an IncQuery project with exactly the same pattern definitions like already given above. The result is the same.
Ambiguous variable type defintions: If I try to get directly the Sub2 over "contains" reference(without asking for the abstract SuperClass).
Variable has a type which has multiple definitions: If I try to get the abstract SuperClass over "contains" reference.
But I also do not see any differences between how this Common model is being referenced by the Java and Props. The plugin dependency structure is the same, and even every option in the genmodels.
So I am kind of stuck, but I would definitely get back here, if I can come up with something newer.
Thanks a lot again.
Best regards,
Emre
|
|
|
Goto Forum:
Current Time: Sat Nov 09 03:01:50 GMT 2024
Powered by FUDForum. Page generated in 0.02952 seconds |
] 
Search
Help
Register
Login
Home
