[Xtext] Problem : Cannot find compatible feature foo in sealed EClass [message #43269] |
Thu, 07 May 2009 08:46  |
Eclipse User |
|
|
|
Originally posted by: sderrienREMOVE.irisa.fr
Hello,
I want to define a DSL for an existing ecore meta model.
In this model I have an AbstractClass which has a feature named foo, and
a ConcreteClass that inherits from this AbstractClass.
I want to write a Rule to create an initialized instance of
ConcreteClass in which I initialize the feature foo (inherited from
AbstractClass).
I use the following Xtext Rule for this
MyRule1 returns ConcreteClass:
foo+=AnotherRule
However, I get the following error :
Cannot find compatible feature foo in sealed EClass ConcreteClass from
imported package http://mypackageURI.
Is there a way to specify that the feature belongs to the ParentClass
(something like super.foo+=AnotherRule) ? If not is there any alternive
solution ?
Steven Derrien
|
|
|
|
Re: [Xtext] Problem : Cannot find compatible feature foo in sealed EClass [message #43419 is a reply to message #43326] |
Thu, 07 May 2009 15:41   |
Eclipse User |
|
|
|
Originally posted by: sderrienREMOVE.irisa.fr
Hello Heiko,
Thank you for your help.
Actually my example was not correct, since my DSL involves
cross-references. Here is the actual code snippet :
import "http://www.irisa.fr/cairn/datapath/fsm" as fsm
import "http://www.irisa.fr/cairn/datapath/port" as ports
....
FSMRule returns fsm::FSM :
ports+=InputPortRule terms+=PredicateTermRule;
InputPortRule returns ports::InControlPort:
name=ID;
PredicateTermRule returns fsm::PredicateTerm :
(negated?=('!'))? flag=[ports::InControlPort];
^^^^
It is the flag feature that causes the error message :
"Cannot find compatible feature flag in sealed EClass PredicateTerm from
imported package http://www.irisa.fr/cairn/datapath/fsm."
In the ecore file defining the fsm package, the EClass *PredicateTerm*
has a EReference feature named *flag* of type *InControlPort*, with
upperBound set to 1, and containment set to false.
Unless I am missing something obvious, everything seems consistent
to me (I double-checked before writing this mail).
Do you have any hints ?
Thanks in advance,
Steven
Heiko Behrens a écrit :
> Hey Steven,
>
> the problem here is that Xtext tries to find a proper feature that
> corresponds to "foo+=AnotherRule" in your meta model. Each assignment
> has to match with respect to its name, cardinality and type.
>
> Just looking at your snippet I would guess that AnotherRules does not
> return the proper type for the given feature foo defined in your
> existing meta model.
>
> This should work:
>
> MyRule returns ConcreteClass:
> foo=AnotherRule;
>
> AnotherRule returns TypeOfFeatureFooInConcreteClass:
> some?="rule that matches return type";
>
> Also, please be aware that "+=" and "=" expect different configurations
> of your meta model. The former expects a multi value containment feature
> where as the latter expect a single value containment.
>
> Hope that helps,
> Heiko
|
|
|
Re: [Xtext] Problem : Cannot find compatible feature foo in sealed EClass [message #43512 is a reply to message #43419] |
Fri, 08 May 2009 02:37   |
Eclipse User |
|
|
|
You use namespace URIs this implies that you have installed both
EPackages into the workbench. Did you?
We also need to have a look at the EPackages in order track the problem
down.
Sven
Steven Derrien schrieb:
> Hello Heiko,
>
> Thank you for your help.
>
> Actually my example was not correct, since my DSL involves
> cross-references. Here is the actual code snippet :
>
> import "http://www.irisa.fr/cairn/datapath/fsm" as fsm
> import "http://www.irisa.fr/cairn/datapath/port" as ports
>
> ...
>
> FSMRule returns fsm::FSM :
> ports+=InputPortRule terms+=PredicateTermRule;
>
>
> InputPortRule returns ports::InControlPort:
> name=ID;
>
> PredicateTermRule returns fsm::PredicateTerm :
> (negated?=('!'))? flag=[ports::InControlPort];
> ^^^^
>
> It is the flag feature that causes the error message :
>
> "Cannot find compatible feature flag in sealed EClass PredicateTerm from
> imported package http://www.irisa.fr/cairn/datapath/fsm."
>
> In the ecore file defining the fsm package, the EClass *PredicateTerm*
> has a EReference feature named *flag* of type *InControlPort*, with
> upperBound set to 1, and containment set to false.
>
> Unless I am missing something obvious, everything seems consistent
> to me (I double-checked before writing this mail).
>
> Do you have any hints ?
>
> Thanks in advance,
>
> Steven
>
>
> Heiko Behrens a écrit :
>> Hey Steven,
>>
>> the problem here is that Xtext tries to find a proper feature that
>> corresponds to "foo+=AnotherRule" in your meta model. Each assignment
>> has to match with respect to its name, cardinality and type.
>>
>> Just looking at your snippet I would guess that AnotherRules does not
>> return the proper type for the given feature foo defined in your
>> existing meta model.
>>
>> This should work:
>>
>> MyRule returns ConcreteClass:
>> foo=AnotherRule;
>>
>> AnotherRule returns TypeOfFeatureFooInConcreteClass:
>> some?="rule that matches return type";
>>
>> Also, please be aware that "+=" and "=" expect different
>> configurations of your meta model. The former expects a multi value
>> containment feature where as the latter expect a single value
>> containment.
>>
>> Hope that helps,
>> Heiko
|
|
|
Re: [Xtext] Problem : Cannot find compatible feature foo in sealed EClass [message #43662 is a reply to message #43512] |
Fri, 08 May 2009 05:54   |
Eclipse User |
|
|
|
Originally posted by: sderrienREMOVE.irisa.fr
Hi Sven,
Sven Efftinge a écrit :
> You use namespace URIs this implies that you have installed both
> EPackages into the workbench. Did you?
Yes, I can see them in the EMF package registry view. Anyhow, if
packages are not registered, the Xtext editor shows an error directly on
the corresponding *import* line.
> We also need to have a look at the EPackages in order track the problem
> down.
I'll see If I can send them to you by mail.
Thanks for the support.
Steven
>
> Sven
>
>
> Steven Derrien schrieb:
>> Hello Heiko,
>>
>> Thank you for your help.
>>
>> Actually my example was not correct, since my DSL involves
>> cross-references. Here is the actual code snippet :
>>
>> import "http://www.irisa.fr/cairn/datapath/fsm" as fsm
>> import "http://www.irisa.fr/cairn/datapath/port" as ports
>>
>> ...
>>
>> FSMRule returns fsm::FSM :
>> ports+=InputPortRule terms+=PredicateTermRule;
>>
>>
>> InputPortRule returns ports::InControlPort:
>> name=ID;
>>
>> PredicateTermRule returns fsm::PredicateTerm :
>> (negated?=('!'))? flag=[ports::InControlPort];
>> ^^^^
>>
>> It is the flag feature that causes the error message :
>>
>> "Cannot find compatible feature flag in sealed EClass PredicateTerm
>> from imported package http://www.irisa.fr/cairn/datapath/fsm."
>>
>> In the ecore file defining the fsm package, the EClass *PredicateTerm*
>> has a EReference feature named *flag* of type *InControlPort*, with
>> upperBound set to 1, and containment set to false.
>>
>> Unless I am missing something obvious, everything seems consistent
>> to me (I double-checked before writing this mail).
>>
>> Do you have any hints ?
>>
>> Thanks in advance,
>>
>> Steven
>>
>>
>> Heiko Behrens a écrit :
>>> Hey Steven,
>>>
>>> the problem here is that Xtext tries to find a proper feature that
>>> corresponds to "foo+=AnotherRule" in your meta model. Each assignment
>>> has to match with respect to its name, cardinality and type.
>>>
>>> Just looking at your snippet I would guess that AnotherRules does not
>>> return the proper type for the given feature foo defined in your
>>> existing meta model.
>>>
>>> This should work:
>>>
>>> MyRule returns ConcreteClass:
>>> foo=AnotherRule;
>>>
>>> AnotherRule returns TypeOfFeatureFooInConcreteClass:
>>> some?="rule that matches return type";
>>>
>>> Also, please be aware that "+=" and "=" expect different
>>> configurations of your meta model. The former expects a multi value
>>> containment feature where as the latter expect a single value
>>> containment.
>>>
>>> Hope that helps,
>>> Heiko
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.28734 seconds