Mapping eType of reference to eType of attribute [message #1001891] |
Thu, 17 January 2013 14:15 |
|
Hi,
I define an ecore model with Java interfaces:
import java.net.InetAddress;
/**
* @model
*/
public interface net {
/**
* @model dataType="java.net.InetAddress"
*/
InetAddress getAddress();
}
and
import java.net.InetAddress;
import java.util.List;
/**
* @model
*/
public interface nic {
/**
* @model containment="true" required="false" type="java.net.InetAddress"
*/
List<InetAddress> getAddresses();
}
Now, I would expect that ecore uses the same eType for the attribute net.address and the reference nic.addresses. However, it uses two different eTypes: InetAddress for the attribute and InetAddress_1 for the reference.
How can I enforce that the same eType is used? And why is that happening anyways?
I'm using Eclispe Juno.
Thanks,
Martin
[Updated on: Thu, 24 January 2013 11:56] Report message to a moderator
|
|
|
Re: Mapping eType of reference to eType of attribute [message #1002083 is a reply to message #1001891] |
Thu, 17 January 2013 22:32 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
The eType of an attribute must be a DataType, while the eType of a
Reference must be an EClass, hence it generates and uses another type
for the reference.
Hallvard
On 17.01.13 07.57, Martin C. wrote:
> Hi,
>
> I define an ecore model with Java interfaces:
>
>
> import java.net.InetAddress;
>
> /**
> * @model dataType="java.net.InetAddress"
> */
> public interface net {
> InetAddress getAddress();
> }
>
>
> and
>
>
> import java.net.InetAddress;
> import java.util.List;
>
> /**
> * @model containment="true" required="false" type="java.net.InetAddress"
> */
> public interface nic {
> List<InetAddress> getAddresses();
> }
>
>
> Now, I would expect that ecore uses the same eType for the attribute
> net.address and the reference nic.addresses. However, it uses two
> different eTypes: InetAddress for the attribute and InetAddress_1 for
> the reference.
>
> How can I enforce that the same eType is used? And why is that happening
> anyways?
>
> I'm using Eclispe Juno.
>
> Thanks,
>
> Martin
|
|
|
|
Re: Mapping eType of reference to eType of attribute [message #1005064 is a reply to message #1002237] |
Thu, 24 January 2013 12:07 |
|
Let's use a list:
- Thanks Hallvard, that explained what happens.
- Also thanks Ed for the pointer to Xcore. However, I'm not quite sure if I want to use Xcore. It looks already so similar to Java that I could also model with Java classes themselves.
- Is there a way to specify the name of the EClass/eType? So I could get rid of the annoying "_1" name.
- BTW: I pasted the annotations to the wrong statements in my code examples, because I simplified the code to what the problem is. But it's fixed now.
|
|
|
Re: Mapping eType of reference to eType of attribute [message #1005084 is a reply to message #1005064] |
Thu, 24 January 2013 13:02 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Martin,
Comments below.
On 24/01/2013 1:07 PM, Martin C. wrote:
> Let's use a list:
>
> Thanks Hallvard, that explained what happens.
> Also thanks Ed for the pointer to Xcore. However, I'm not quite sure
> if I want to use Xcore. It looks already so similar to Java that I
> could also model with Java classes themselves.
Yes, but as I said, there is little in the way of feedback on what's
wrong with your @model annotations. In your example, not a single one
of the attributes you've specified was sensible in that location.
> Is there a way to specify the name of the EClass/eType? So I could get
> rid of the annoying "_1" name.
Have a look at the generated XyzPackage implementation's @model
annotations to see what data types you've ended up with. Once they're
their and they're marked @model, you have to delete them to get rid of them.
> BTW: I pasted the annotations to the wrong statements in my code
> examples, because I simplified the code to what the problem is. But
> it's fixed now.
What does it look like now?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.03672 seconds