Home » Modeling » EMF » [xcore] refering to classes in non XCore ecore models
| [xcore] refering to classes in non XCore ecore models [message #895988] |
Mon, 16 July 2012 14:24  |
Eclipse User |
|
|
|
Hi,
in an XCore model/plug-in I'm trying to refer to another EClass modeled in a regular .ecore file in another plugin.
The former plug-in depends on the latter, the import seems to work, but in the line "refers" (see example below), it says
"Multiple markers at this line - A generic type in this context must refer to a classifier or a type parameter -
Couldn't resolve reference to GenBase 'Blub'."
------Example------
package org.example.coolpackage
import org.example.anothercoolpackage.Blub
class Bla{
refers Blub b
}
------EndExample------
Am I missing a reference to the ecore model / it's genmodel?
Thanks for helping
Joel
|
|
| |
| Re: [xcore] refering to classes in non XCore ecore models [message #896068 is a reply to message #896052] |
Tue, 17 July 2012 03:07  |
| Eclipse User |
|
|
|
Hi Ed,
Works. Thanks for the explanation.
Maybe you should add this to your XCore wiki article... I'm sure others will come across this.
Ciao
Joel
On 17.07.2012 07:28, Ed Merks wrote:
> Joel,
>
> Comments below.
>
> On 16/07/2012 8:24 PM, Joel Greenyer wrote:
>> Hi,
>> in an XCore model/plug-in I'm trying to refer to another EClass modeled in a regular .ecore file in another plugin.
>>
>> The former plug-in depends on the latter, the import seems to work, but in the line "refers" (see example below), it says
>>
>> "Multiple markers at this line - A generic type in this context must refer to a classifier or a type parameter -
>> Couldn't resolve reference to GenBase 'Blub'."
>>
>> ------Example------
>> package org.example.coolpackage
>>
>> import org.example.anothercoolpackage.Blub
>>
>> class Bla{
>> refers Blub b
>> }
>> ------EndExample------
>>
>> Am I missing a reference to the ecore model / it's genmodel?
> The other model's project must have an Xtext nature (File->Configure->Add Xtext nature) in order for Xtext's indexing infrastructure to index it and that's needed in order for Xcore to know about the indexed *.genmodel resources in that project. Failing that, the *.genmodel resources need to be on the classpath, which is the case only when a bundle is properly deployed as runtime bundle to include the model folder in the bundle and where the classes are in "." rather than "bin" as they are at development time. It's an annoying and long standing issue that the PDE doesn't put everything that's on the actual runtime path after deployment on the classpath at development time...
>>
>> Thanks for helping
>>
>> Joel
>
>
|
|
|
| Re: [xcore] refering to classes in non XCore ecore models [message #896219 is a reply to message #896068] |
Tue, 17 July 2012 11:39 |
| Eclipse User |
|
|
|
Hi,
I have another problem.
If I say
class Bla extends Blub{
....
}
I have the problem that in the generated Package class there is a line
int BLA_OPERATION_COUNT = AnothercoolpackagePackage.BLUB_OPERATION_COUNT + 0;
where "BLUB_OPERATION_COUNT cannot be resolved or is not a field", i.e., the ...__OPERATION_COUNT field is not generated for the class in the package generated from standard ecore-&genmodel.
Is there anything I can do about that?
Thanks
Joel
On 17.07.2012 09:07, Joel Greenyer wrote:
> Hi Ed,
> Works. Thanks for the explanation.
> Maybe you should add this to your XCore wiki article... I'm sure others will come across this.
>
> Ciao
>
> Joel
>
> On 17.07.2012 07:28, Ed Merks wrote:
>> Joel,
>>
>> Comments below.
>>
>> On 16/07/2012 8:24 PM, Joel Greenyer wrote:
>>> Hi,
>>> in an XCore model/plug-in I'm trying to refer to another EClass modeled in a regular .ecore file in another plugin.
>>>
>>> The former plug-in depends on the latter, the import seems to work, but in the line "refers" (see example below), it says
>>>
>>> "Multiple markers at this line - A generic type in this context must refer to a classifier or a type parameter -
>>> Couldn't resolve reference to GenBase 'Blub'."
>>>
>>> ------Example------
>>> package org.example.coolpackage
>>>
>>> import org.example.anothercoolpackage.Blub
>>>
>>> class Bla{
>>> refers Blub b
>>> }
>>> ------EndExample------
>>>
>>> Am I missing a reference to the ecore model / it's genmodel?
>> The other model's project must have an Xtext nature (File->Configure->Add Xtext nature) in order for Xtext's indexing infrastructure to index it and that's needed in order for Xcore to know about the indexed *.genmodel resources in that project. Failing that, the *.genmodel resources need to be on the classpath, which is the case only when a bundle is properly deployed as runtime bundle to include the model folder in the bundle and where the classes are in "." rather than "bin" as they are at development time. It's an annoying and long standing issue that the PDE doesn't put everything that's on the actual runtime path after deployment on the classpath at development time...
>>>
>>> Thanks for helping
>>>
>>> Joel
>>
>>
>
>
|
|
|
| Re: [xcore] refering to classes in non XCore ecore models [message #896342 is a reply to message #896219] |
Wed, 18 July 2012 02:54 |
| Eclipse User |
|
|
|
Joel,
The base model must support Operation Reflection (it's false by default)
or the derived model must not (it's true by default for Xcore models).
As you probably know, you can use the properties view to set such things
for your Xcore model to produce the necessary @GenModel annotations.
On 17/07/2012 5:39 PM, Joel Greenyer wrote:
> Hi,
> I have another problem.
> If I say
>
> class Bla extends Blub{
> ...
> }
>
> I have the problem that in the generated Package class there is a line
>
> int BLA_OPERATION_COUNT =
> AnothercoolpackagePackage.BLUB_OPERATION_COUNT + 0;
>
> where "BLUB_OPERATION_COUNT cannot be resolved or is not a field",
> i.e., the ...__OPERATION_COUNT field is not generated for the class in
> the package generated from standard ecore-&genmodel.
>
> Is there anything I can do about that?
>
> Thanks
>
> Joel
>
>
> On 17.07.2012 09:07, Joel Greenyer wrote:
>> Hi Ed,
>> Works. Thanks for the explanation.
>> Maybe you should add this to your XCore wiki article... I'm sure
>> others will come across this.
>>
>> Ciao
>>
>> Joel
>>
>> On 17.07.2012 07:28, Ed Merks wrote:
>>> Joel,
>>>
>>> Comments below.
>>>
>>> On 16/07/2012 8:24 PM, Joel Greenyer wrote:
>>>> Hi,
>>>> in an XCore model/plug-in I'm trying to refer to another EClass
>>>> modeled in a regular .ecore file in another plugin.
>>>>
>>>> The former plug-in depends on the latter, the import seems to work,
>>>> but in the line "refers" (see example below), it says
>>>>
>>>> "Multiple markers at this line - A generic type in this context
>>>> must refer to a classifier or a type parameter -
>>>> Couldn't resolve reference to GenBase 'Blub'."
>>>>
>>>> ------Example------
>>>> package org.example.coolpackage
>>>>
>>>> import org.example.anothercoolpackage.Blub
>>>>
>>>> class Bla{
>>>> refers Blub b
>>>> }
>>>> ------EndExample------
>>>>
>>>> Am I missing a reference to the ecore model / it's genmodel?
>>> The other model's project must have an Xtext nature
>>> (File->Configure->Add Xtext nature) in order for Xtext's indexing
>>> infrastructure to index it and that's needed in order for Xcore to
>>> know about the indexed *.genmodel resources in that project.
>>> Failing that, the *.genmodel resources need to be on the classpath,
>>> which is the case only when a bundle is properly deployed as runtime
>>> bundle to include the model folder in the bundle and where the
>>> classes are in "." rather than "bin" as they are at development
>>> time. It's an annoying and long standing issue that the PDE doesn't
>>> put everything that's on the actual runtime path after deployment on
>>> the classpath at development time...
>>>>
>>>> Thanks for helping
>>>>
>>>> Joel
>>>
>>>
>>
>>
>
>
|
|
|
| Re: [xcore] refering to classes in non XCore ecore models [message #896508 is a reply to message #896342] |
Wed, 18 July 2012 11:12 |
| Eclipse User |
|
|
|
great.
Thanks!
On 18.07.2012 08:54, Ed Merks wrote:
> Joel,
>
> The base model must support Operation Reflection (it's false by default) or the derived model must not (it's true by default for Xcore models). As you probably know, you can use the properties view to set such things for your Xcore model to produce the necessary @GenModel annotations.
>
>
> On 17/07/2012 5:39 PM, Joel Greenyer wrote:
>> Hi,
>> I have another problem.
>> If I say
>>
>> class Bla extends Blub{
>> ...
>> }
>>
>> I have the problem that in the generated Package class there is a line
>>
>> int BLA_OPERATION_COUNT = AnothercoolpackagePackage.BLUB_OPERATION_COUNT + 0;
>>
>> where "BLUB_OPERATION_COUNT cannot be resolved or is not a field", i.e., the ...__OPERATION_COUNT field is not generated for the class in the package generated from standard ecore-&genmodel.
>>
>> Is there anything I can do about that?
>>
>> Thanks
>>
>> Joel
>>
>>
>> On 17.07.2012 09:07, Joel Greenyer wrote:
>>> Hi Ed,
>>> Works. Thanks for the explanation.
>>> Maybe you should add this to your XCore wiki article... I'm sure others will come across this.
>>>
>>> Ciao
>>>
>>> Joel
>>>
>>> On 17.07.2012 07:28, Ed Merks wrote:
>>>> Joel,
>>>>
>>>> Comments below.
>>>>
>>>> On 16/07/2012 8:24 PM, Joel Greenyer wrote:
>>>>> Hi,
>>>>> in an XCore model/plug-in I'm trying to refer to another EClass modeled in a regular .ecore file in another plugin.
>>>>>
>>>>> The former plug-in depends on the latter, the import seems to work, but in the line "refers" (see example below), it says
>>>>>
>>>>> "Multiple markers at this line - A generic type in this context must refer to a classifier or a type parameter -
>>>>> Couldn't resolve reference to GenBase 'Blub'."
>>>>>
>>>>> ------Example------
>>>>> package org.example.coolpackage
>>>>>
>>>>> import org.example.anothercoolpackage.Blub
>>>>>
>>>>> class Bla{
>>>>> refers Blub b
>>>>> }
>>>>> ------EndExample------
>>>>>
>>>>> Am I missing a reference to the ecore model / it's genmodel?
>>>> The other model's project must have an Xtext nature (File->Configure->Add Xtext nature) in order for Xtext's indexing infrastructure to index it and that's needed in order for Xcore to know about the indexed *.genmodel resources in that project. Failing that, the *.genmodel resources need to be on the classpath, which is the case only when a bundle is properly deployed as runtime bundle to include the model folder in the bundle and where the classes are in "." rather than "bin" as they are at development time. It's an annoying and long standing issue that the PDE doesn't put everything that's on the actual runtime path after deployment on the classpath at development time...
>>>>>
>>>>> Thanks for helping
>>>>>
>>>>> Joel
>>>>
>>>>
>>>
>>>
>>
>>
>
|
|
| |
| Re: [xcore] refering to classes in non XCore ecore models [message #898888 is a reply to message #898873] |
Sat, 28 July 2012 15:54 |
| Eclipse User |
|
|
|
Max,
At a glance, I suspect that the base model doesn't support reflective
operation invocation while your derived model, by default, does. Adding
@GenModel(operationReflection="false") on the package declaration should
avoid that.
On 28/07/2012 7:50 PM, Max Goltzsche wrote:
> Hello,
>
> I've got a similar problem extending
> TypesPackage::JvmIdentifiableElement.
> The following xcore class is valid:
> ---- BEGIN XCORE EXAMPLE ----
> class MyCustomJvmIdentifiableElement extends JvmIdenfiableElement {
> String name
>
> op String getIdentifier() {
> name
> }
>
> op String getSimpleName() {
> name
> }
>
> op String getQualifiedName() {
> name
> }
>
> op String getQualifiedName(char separator) {
> name
> }
> }
> ---- END XCORE EXAMPLE ----
>
> But the generated Java function int eDerivedOperationID(int, Class<?>)
> contains errors: The int constants representing the super type's
> operations do not exist:
> TypesPackage.JVM_IDENTIFIABLE_ELEMENT___GET_IDENTIFIER,
> TypesPackage.JVM_IDENTIFIABLE_ELEMENT___GET_SIMPLE_NAME,
> TypesPackage.JVM_IDENTIFIABLE_ELEMENT___GET_QUALIFIED_NAME,
> TypesPackage.JVM_IDENTIFIABLE_ELEMENT___GET_QUALIFIED_NAME__CHAR
>
> How to solve this error?
>
> best regards,
> Max
|
|
| |
Goto Forum:
Current Time: Tue Jul 08 01:25:01 EDT 2025
Powered by FUDForum. Page generated in 0.10578 seconds |
Home