Home » Modeling » EMF » extending ecore classes
| extending ecore classes [message #426735] |
Mon, 19 January 2009 18:47  |
Eclipse User |
|
|
|
Originally posted by: udo.poehner.freenet.de
Hello,
I want to add additional features to the ecore classes using the
decorator-pattern.
A simple example would be adding a feature to EPackage.
I use my own interface and the EPackage-interface.
Create the code from genmodel.
I can launch the plugin and create an extended version of EPackage.
By clicking on the newly created item I get a "MissingResourceException"
because something like that "_UI_EClassifier_ePackage_feature" is not found.
Those "resources" can be found in the "plugin.properties" file of the
edit code.
But the searched string is not contained in my version of the file.
Copying lines from the ecore edit code into my "plugin.properties" file
everything seems to work fine.
Adding a dependency between my edit code and the ecore edit code didn't
work.
Is it really necessary to do copy and paste?
Cheers,
Udo
|
|
| |
| Re: extending ecore classes [message #426816 is a reply to message #426760] |
Wed, 21 January 2009 14:01  |
| Eclipse User |
|
|
|
Originally posted by: udo.poehner.freenet.de
Hello,
I thought about your advice using EAnnotations to get the additional
features into ecore.
But I am not sure if I understood how it is supposed to do.
I would take the original ecore model and add annotations to the
according classes?
Thanks,
Udo
Ed Merks schrieb:
> Udo,
>
> Comments below.
>
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I want to add additional features to the ecore classes using the
>> decorator-pattern.
> Extending Ecore. I always tell people not to do that. That's what
> EAnnotations are for.
>>
>> A simple example would be adding a feature to EPackage.
>> I use my own interface and the EPackage-interface.
>> Create the code from genmodel.
>>
>> I can launch the plugin and create an extended version of EPackage.
>>
>> By clicking on the newly created item I get a
>> "MissingResourceException" because something like that
>> "_UI_EClassifier_ePackage_feature" is not found.
>>
>> Those "resources" can be found in the "plugin.properties" file of the
>> edit code.
>> But the searched string is not contained in my version of the file.
>>
>> Copying lines from the ecore edit code into my "plugin.properties"
>> file everything seems to work fine.
>>
>> Adding a dependency between my edit code and the ecore edit code
>> didn't work.
>>
>> Is it really necessary to do copy and paste?
> Maybe the plugin class just needs to specify EcoreEditPlugin as a
> delegate...
>
> public CodeGenEcoreUIPlugin() {
> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
> EcoreEditPlugin.INSTANCE,});
> }
>>
>>
>> Cheers,
>> Udo
|
|
|
| Re: extending ecore classes [message #426818 is a reply to message #426816] |
Wed, 21 January 2009 14:31 |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Udo,
Comments below.
Udo Pöhner wrote:
> Hello,
>
> I thought about your advice using EAnnotations to get the additional
> features into ecore.
>
> But I am not sure if I understood how it is supposed to do.
>
> I would take the original ecore model and add annotations to the
> according classes?
EAnnotations allow you to decorate an Ecore instance without extending
any Ecore classes at or below EModelElement. If you look closely at
EAnnotation itself, you can see it allow you to contain or reference
arbitrary other EObject. In this way, if String to String properties
are not sufficient, you can contain you own modeled data as well. You'd
want to use GenPackage set to Initialize by Loading in that case so that
instances of your objects will be created in the generated package.
>
> Thanks,
> Udo
>
>
>
>
> Ed Merks schrieb:
>> Udo,
>>
>> Comments below.
>>
>>
>> Udo Pöhner wrote:
>>> Hello,
>>>
>>> I want to add additional features to the ecore classes using the
>>> decorator-pattern.
>> Extending Ecore. I always tell people not to do that. That's what
>> EAnnotations are for.
>>>
>>> A simple example would be adding a feature to EPackage.
>>> I use my own interface and the EPackage-interface.
>>> Create the code from genmodel.
>>>
>>> I can launch the plugin and create an extended version of EPackage.
>>>
>>> By clicking on the newly created item I get a
>>> "MissingResourceException" because something like that
>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>
>>> Those "resources" can be found in the "plugin.properties" file of
>>> the edit code.
>>> But the searched string is not contained in my version of the file.
>>>
>>> Copying lines from the ecore edit code into my "plugin.properties"
>>> file everything seems to work fine.
>>>
>>> Adding a dependency between my edit code and the ecore edit code
>>> didn't work.
>>>
>>> Is it really necessary to do copy and paste?
>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>> delegate...
>>
>> public CodeGenEcoreUIPlugin() {
>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>> EcoreEditPlugin.INSTANCE,});
>> }
>>>
>>>
>>> Cheers,
>>> Udo
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: extending ecore classes [message #426829 is a reply to message #426818] |
Thu, 22 January 2009 08:18 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
I believe the real problem comes when you start utilizing generics, I
think one of the concerns when introducing generics is to keep the model
as compact as possible, but this introduced usage complexity. Now, with
the absence of eAnnotations in EGenericType, the annotation approach is
simply impossible.
Ed Merks wrote:
> Udo,
>
> Comments below.
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I thought about your advice using EAnnotations to get the additional
>> features into ecore.
>>
>> But I am not sure if I understood how it is supposed to do.
>>
>> I would take the original ecore model and add annotations to the
>> according classes?
> EAnnotations allow you to decorate an Ecore instance without extending
> any Ecore classes at or below EModelElement. If you look closely at
> EAnnotation itself, you can see it allow you to contain or reference
> arbitrary other EObject. In this way, if String to String properties
> are not sufficient, you can contain you own modeled data as well. You'd
> want to use GenPackage set to Initialize by Loading in that case so that
> instances of your objects will be created in the generated package.
>>
>> Thanks,
>> Udo
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Udo,
>>>
>>> Comments below.
>>>
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I want to add additional features to the ecore classes using the
>>>> decorator-pattern.
>>> Extending Ecore. I always tell people not to do that. That's what
>>> EAnnotations are for.
>>>>
>>>> A simple example would be adding a feature to EPackage.
>>>> I use my own interface and the EPackage-interface.
>>>> Create the code from genmodel.
>>>>
>>>> I can launch the plugin and create an extended version of EPackage.
>>>>
>>>> By clicking on the newly created item I get a
>>>> "MissingResourceException" because something like that
>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>
>>>> Those "resources" can be found in the "plugin.properties" file of
>>>> the edit code.
>>>> But the searched string is not contained in my version of the file.
>>>>
>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>> file everything seems to work fine.
>>>>
>>>> Adding a dependency between my edit code and the ecore edit code
>>>> didn't work.
>>>>
>>>> Is it really necessary to do copy and paste?
>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>> delegate...
>>>
>>> public CodeGenEcoreUIPlugin() {
>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>> EcoreEditPlugin.INSTANCE,});
>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Udo
|
|
|
| Re: extending ecore classes [message #426830 is a reply to message #426818] |
Thu, 22 January 2009 08:20 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
I believe the real problem comes when you start utilizing generics, I
think one of the concerns when introducing generics is to keep the model
as compact as possible, but this introduced usage complexity. Now, with
the absence of eAnnotations in EGenericType, the annotation approach is
simply impossible.
Ed Merks wrote:
> Udo,
>
> Comments below.
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I thought about your advice using EAnnotations to get the additional
>> features into ecore.
>>
>> But I am not sure if I understood how it is supposed to do.
>>
>> I would take the original ecore model and add annotations to the
>> according classes?
> EAnnotations allow you to decorate an Ecore instance without extending
> any Ecore classes at or below EModelElement. If you look closely at
> EAnnotation itself, you can see it allow you to contain or reference
> arbitrary other EObject. In this way, if String to String properties
> are not sufficient, you can contain you own modeled data as well. You'd
> want to use GenPackage set to Initialize by Loading in that case so that
> instances of your objects will be created in the generated package.
>>
>> Thanks,
>> Udo
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Udo,
>>>
>>> Comments below.
>>>
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I want to add additional features to the ecore classes using the
>>>> decorator-pattern.
>>> Extending Ecore. I always tell people not to do that. That's what
>>> EAnnotations are for.
>>>>
>>>> A simple example would be adding a feature to EPackage.
>>>> I use my own interface and the EPackage-interface.
>>>> Create the code from genmodel.
>>>>
>>>> I can launch the plugin and create an extended version of EPackage.
>>>>
>>>> By clicking on the newly created item I get a
>>>> "MissingResourceException" because something like that
>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>
>>>> Those "resources" can be found in the "plugin.properties" file of
>>>> the edit code.
>>>> But the searched string is not contained in my version of the file.
>>>>
>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>> file everything seems to work fine.
>>>>
>>>> Adding a dependency between my edit code and the ecore edit code
>>>> didn't work.
>>>>
>>>> Is it really necessary to do copy and paste?
>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>> delegate...
>>>
>>> public CodeGenEcoreUIPlugin() {
>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>> EcoreEditPlugin.INSTANCE,});
>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Udo
|
|
|
| Re: extending ecore classes [message #426831 is a reply to message #426818] |
Thu, 22 January 2009 08:25 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
I believe the real problem comes when you start utilizing generics, I
think one of the concerns when introducing generics is to keep the model
as compact as possible, but this introduced usage complexity. Now, with
the absence of eAnnotations in EGenericType, the annotation approach is
simply impossible.
Ed Merks wrote:
> Udo,
>
> Comments below.
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I thought about your advice using EAnnotations to get the additional
>> features into ecore.
>>
>> But I am not sure if I understood how it is supposed to do.
>>
>> I would take the original ecore model and add annotations to the
>> according classes?
> EAnnotations allow you to decorate an Ecore instance without extending
> any Ecore classes at or below EModelElement. If you look closely at
> EAnnotation itself, you can see it allow you to contain or reference
> arbitrary other EObject. In this way, if String to String properties
> are not sufficient, you can contain you own modeled data as well. You'd
> want to use GenPackage set to Initialize by Loading in that case so that
> instances of your objects will be created in the generated package.
>>
>> Thanks,
>> Udo
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Udo,
>>>
>>> Comments below.
>>>
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I want to add additional features to the ecore classes using the
>>>> decorator-pattern.
>>> Extending Ecore. I always tell people not to do that. That's what
>>> EAnnotations are for.
>>>>
>>>> A simple example would be adding a feature to EPackage.
>>>> I use my own interface and the EPackage-interface.
>>>> Create the code from genmodel.
>>>>
>>>> I can launch the plugin and create an extended version of EPackage.
>>>>
>>>> By clicking on the newly created item I get a
>>>> "MissingResourceException" because something like that
>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>
>>>> Those "resources" can be found in the "plugin.properties" file of
>>>> the edit code.
>>>> But the searched string is not contained in my version of the file.
>>>>
>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>> file everything seems to work fine.
>>>>
>>>> Adding a dependency between my edit code and the ecore edit code
>>>> didn't work.
>>>>
>>>> Is it really necessary to do copy and paste?
>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>> delegate...
>>>
>>> public CodeGenEcoreUIPlugin() {
>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>> EcoreEditPlugin.INSTANCE,});
>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Udo
|
|
|
| Re: extending ecore classes [message #426832 is a reply to message #426818] |
Thu, 22 January 2009 08:33 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
I believe the real problem comes when you start utilizing generics, I
think one of the concerns when introducing generics is to keep the model
as compact as possible, but this introduced usage complexity. Now, with
the absence of eAnnotations in EGenericType, the annotation approach is
simply impossible.
Ed Merks wrote:
> Udo,
>
> Comments below.
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I thought about your advice using EAnnotations to get the additional
>> features into ecore.
>>
>> But I am not sure if I understood how it is supposed to do.
>>
>> I would take the original ecore model and add annotations to the
>> according classes?
> EAnnotations allow you to decorate an Ecore instance without extending
> any Ecore classes at or below EModelElement. If you look closely at
> EAnnotation itself, you can see it allow you to contain or reference
> arbitrary other EObject. In this way, if String to String properties
> are not sufficient, you can contain you own modeled data as well. You'd
> want to use GenPackage set to Initialize by Loading in that case so that
> instances of your objects will be created in the generated package.
>>
>> Thanks,
>> Udo
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Udo,
>>>
>>> Comments below.
>>>
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I want to add additional features to the ecore classes using the
>>>> decorator-pattern.
>>> Extending Ecore. I always tell people not to do that. That's what
>>> EAnnotations are for.
>>>>
>>>> A simple example would be adding a feature to EPackage.
>>>> I use my own interface and the EPackage-interface.
>>>> Create the code from genmodel.
>>>>
>>>> I can launch the plugin and create an extended version of EPackage.
>>>>
>>>> By clicking on the newly created item I get a
>>>> "MissingResourceException" because something like that
>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>
>>>> Those "resources" can be found in the "plugin.properties" file of
>>>> the edit code.
>>>> But the searched string is not contained in my version of the file.
>>>>
>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>> file everything seems to work fine.
>>>>
>>>> Adding a dependency between my edit code and the ecore edit code
>>>> didn't work.
>>>>
>>>> Is it really necessary to do copy and paste?
>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>> delegate...
>>>
>>> public CodeGenEcoreUIPlugin() {
>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>> EcoreEditPlugin.INSTANCE,});
>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Udo
|
|
|
| Re: extending ecore classes [message #426833 is a reply to message #426818] |
Thu, 22 January 2009 08:42 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
I believe the real problem comes when you start utilizing generics, I
think one of the concerns when introducing generics is to keep the model
as compact as possible, but this introduced usage complexity. Now, with
the absence of eAnnotations in EGenericType, the annotation approach is
simply impossible.
Ed Merks wrote:
> Udo,
>
> Comments below.
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I thought about your advice using EAnnotations to get the additional
>> features into ecore.
>>
>> But I am not sure if I understood how it is supposed to do.
>>
>> I would take the original ecore model and add annotations to the
>> according classes?
> EAnnotations allow you to decorate an Ecore instance without extending
> any Ecore classes at or below EModelElement. If you look closely at
> EAnnotation itself, you can see it allow you to contain or reference
> arbitrary other EObject. In this way, if String to String properties
> are not sufficient, you can contain you own modeled data as well. You'd
> want to use GenPackage set to Initialize by Loading in that case so that
> instances of your objects will be created in the generated package.
>>
>> Thanks,
>> Udo
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Udo,
>>>
>>> Comments below.
>>>
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I want to add additional features to the ecore classes using the
>>>> decorator-pattern.
>>> Extending Ecore. I always tell people not to do that. That's what
>>> EAnnotations are for.
>>>>
>>>> A simple example would be adding a feature to EPackage.
>>>> I use my own interface and the EPackage-interface.
>>>> Create the code from genmodel.
>>>>
>>>> I can launch the plugin and create an extended version of EPackage.
>>>>
>>>> By clicking on the newly created item I get a
>>>> "MissingResourceException" because something like that
>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>
>>>> Those "resources" can be found in the "plugin.properties" file of
>>>> the edit code.
>>>> But the searched string is not contained in my version of the file.
>>>>
>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>> file everything seems to work fine.
>>>>
>>>> Adding a dependency between my edit code and the ecore edit code
>>>> didn't work.
>>>>
>>>> Is it really necessary to do copy and paste?
>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>> delegate...
>>>
>>> public CodeGenEcoreUIPlugin() {
>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>> EcoreEditPlugin.INSTANCE,});
>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Udo
|
|
|
| Re: extending ecore classes [message #426836 is a reply to message #426818] |
Thu, 22 January 2009 10:57 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
I believe the real problem comes when you start utilizing generics, I
think one of the concerns when introducing generics is to keep the model
as compact as possible, but this introduced usage complexity. Now, with
the absence of eAnnotations in EGenericType, the annotation approach is
simply impossible.
Ed Merks wrote:
> Udo,
>
> Comments below.
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I thought about your advice using EAnnotations to get the additional
>> features into ecore.
>>
>> But I am not sure if I understood how it is supposed to do.
>>
>> I would take the original ecore model and add annotations to the
>> according classes?
> EAnnotations allow you to decorate an Ecore instance without extending
> any Ecore classes at or below EModelElement. If you look closely at
> EAnnotation itself, you can see it allow you to contain or reference
> arbitrary other EObject. In this way, if String to String properties
> are not sufficient, you can contain you own modeled data as well. You'd
> want to use GenPackage set to Initialize by Loading in that case so that
> instances of your objects will be created in the generated package.
>>
>> Thanks,
>> Udo
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Udo,
>>>
>>> Comments below.
>>>
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I want to add additional features to the ecore classes using the
>>>> decorator-pattern.
>>> Extending Ecore. I always tell people not to do that. That's what
>>> EAnnotations are for.
>>>>
>>>> A simple example would be adding a feature to EPackage.
>>>> I use my own interface and the EPackage-interface.
>>>> Create the code from genmodel.
>>>>
>>>> I can launch the plugin and create an extended version of EPackage.
>>>>
>>>> By clicking on the newly created item I get a
>>>> "MissingResourceException" because something like that
>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>
>>>> Those "resources" can be found in the "plugin.properties" file of
>>>> the edit code.
>>>> But the searched string is not contained in my version of the file.
>>>>
>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>> file everything seems to work fine.
>>>>
>>>> Adding a dependency between my edit code and the ecore edit code
>>>> didn't work.
>>>>
>>>> Is it really necessary to do copy and paste?
>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>> delegate...
>>>
>>> public CodeGenEcoreUIPlugin() {
>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>> EcoreEditPlugin.INSTANCE,});
>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Udo
|
|
|
| Re: extending ecore classes [message #426841 is a reply to message #426829] |
Thu, 22 January 2009 11:48 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Hossam,
I don't think it's appropriate to decorate generics (EGenericType)
themselves. It's a simple expression language and even Java does not
support annotating such things. It seems to me that it will always be
possible to annotate the model element that contains the generics rather
than decorating the generics directly. I wonder what you're trying to
accomplish that you found impossible?
Hossam Karim wrote:
> I believe the real problem comes when you start utilizing generics, I
> think one of the concerns when introducing generics is to keep the
> model as compact as possible, but this introduced usage complexity.
> Now, with the absence of eAnnotations in EGenericType, the annotation
> approach is simply impossible.
> Ed Merks wrote:
>> Udo,
>>
>> Comments below.
>>
>> Udo Pöhner wrote:
>>> Hello,
>>>
>>> I thought about your advice using EAnnotations to get the additional
>>> features into ecore.
>>>
>>> But I am not sure if I understood how it is supposed to do.
>>>
>>> I would take the original ecore model and add annotations to the
>>> according classes?
>> EAnnotations allow you to decorate an Ecore instance without
>> extending any Ecore classes at or below EModelElement. If you look
>> closely at EAnnotation itself, you can see it allow you to contain or
>> reference arbitrary other EObject. In this way, if String to String
>> properties are not sufficient, you can contain you own modeled data
>> as well. You'd want to use GenPackage set to Initialize by Loading
>> in that case so that instances of your objects will be created in the
>> generated package.
>>>
>>> Thanks,
>>> Udo
>>>
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Udo,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Udo Pöhner wrote:
>>>>> Hello,
>>>>>
>>>>> I want to add additional features to the ecore classes using the
>>>>> decorator-pattern.
>>>> Extending Ecore. I always tell people not to do that. That's what
>>>> EAnnotations are for.
>>>>>
>>>>> A simple example would be adding a feature to EPackage.
>>>>> I use my own interface and the EPackage-interface.
>>>>> Create the code from genmodel.
>>>>>
>>>>> I can launch the plugin and create an extended version of EPackage.
>>>>>
>>>>> By clicking on the newly created item I get a
>>>>> "MissingResourceException" because something like that
>>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>>
>>>>> Those "resources" can be found in the "plugin.properties" file of
>>>>> the edit code.
>>>>> But the searched string is not contained in my version of the file.
>>>>>
>>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>>> file everything seems to work fine.
>>>>>
>>>>> Adding a dependency between my edit code and the ecore edit code
>>>>> didn't work.
>>>>>
>>>>> Is it really necessary to do copy and paste?
>>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>>> delegate...
>>>>
>>>> public CodeGenEcoreUIPlugin() {
>>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>>> EcoreEditPlugin.INSTANCE,});
>>>> }
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Udo
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: extending ecore classes [message #426842 is a reply to message #426836] |
Thu, 22 January 2009 11:49 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Hossam,
I assume you're having problems confirming that your posts are getting
onto the newsgroup, but there are 5 duplicates now, so rest assured they
are showing up. I answered the first post...
Hossam Karim wrote:
> I believe the real problem comes when you start utilizing generics, I
> think one of the concerns when introducing generics is to keep the model
> as compact as possible, but this introduced usage complexity. Now, with
> the absence of eAnnotations in EGenericType, the annotation approach is
> simply impossible.
> Ed Merks wrote:
>> Udo,
>>
>> Comments below.
>>
>> Udo Pöhner wrote:
>>> Hello,
>>>
>>> I thought about your advice using EAnnotations to get the additional
>>> features into ecore.
>>>
>>> But I am not sure if I understood how it is supposed to do.
>>>
>>> I would take the original ecore model and add annotations to the
>>> according classes?
>> EAnnotations allow you to decorate an Ecore instance without
>> extending any Ecore classes at or below EModelElement. If you look
>> closely at EAnnotation itself, you can see it allow you to contain or
>> reference arbitrary other EObject. In this way, if String to String
>> properties are not sufficient, you can contain you own modeled data
>> as well. You'd want to use GenPackage set to Initialize by Loading
>> in that case so that instances of your objects will be created in the
>> generated package.
>>>
>>> Thanks,
>>> Udo
>>>
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Udo,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Udo Pöhner wrote:
>>>>> Hello,
>>>>>
>>>>> I want to add additional features to the ecore classes using the
>>>>> decorator-pattern.
>>>> Extending Ecore. I always tell people not to do that. That's what
>>>> EAnnotations are for.
>>>>>
>>>>> A simple example would be adding a feature to EPackage.
>>>>> I use my own interface and the EPackage-interface.
>>>>> Create the code from genmodel.
>>>>>
>>>>> I can launch the plugin and create an extended version of EPackage.
>>>>>
>>>>> By clicking on the newly created item I get a
>>>>> "MissingResourceException" because something like that
>>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>>
>>>>> Those "resources" can be found in the "plugin.properties" file of
>>>>> the edit code.
>>>>> But the searched string is not contained in my version of the file.
>>>>>
>>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>>> file everything seems to work fine.
>>>>>
>>>>> Adding a dependency between my edit code and the ecore edit code
>>>>> didn't work.
>>>>>
>>>>> Is it really necessary to do copy and paste?
>>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>>> delegate...
>>>>
>>>> public CodeGenEcoreUIPlugin() {
>>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>>> EcoreEditPlugin.INSTANCE,});
>>>> }
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Udo
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: extending ecore classes [message #426843 is a reply to message #426818] |
Thu, 22 January 2009 12:25 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
I believe the real problem comes when you start utilizing generics, I
think one of the concerns when introducing generics is to keep the model
as compact as possible, but this introduced usage complexity. Now, with
the absence of eAnnotations in EGenericType, the annotation approach is
simply impossible.
Ed Merks wrote:
> Udo,
>
> Comments below.
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I thought about your advice using EAnnotations to get the additional
>> features into ecore.
>>
>> But I am not sure if I understood how it is supposed to do.
>>
>> I would take the original ecore model and add annotations to the
>> according classes?
> EAnnotations allow you to decorate an Ecore instance without extending
> any Ecore classes at or below EModelElement. If you look closely at
> EAnnotation itself, you can see it allow you to contain or reference
> arbitrary other EObject. In this way, if String to String properties
> are not sufficient, you can contain you own modeled data as well. You'd
> want to use GenPackage set to Initialize by Loading in that case so that
> instances of your objects will be created in the generated package.
>>
>> Thanks,
>> Udo
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Udo,
>>>
>>> Comments below.
>>>
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I want to add additional features to the ecore classes using the
>>>> decorator-pattern.
>>> Extending Ecore. I always tell people not to do that. That's what
>>> EAnnotations are for.
>>>>
>>>> A simple example would be adding a feature to EPackage.
>>>> I use my own interface and the EPackage-interface.
>>>> Create the code from genmodel.
>>>>
>>>> I can launch the plugin and create an extended version of EPackage.
>>>>
>>>> By clicking on the newly created item I get a
>>>> "MissingResourceException" because something like that
>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>
>>>> Those "resources" can be found in the "plugin.properties" file of
>>>> the edit code.
>>>> But the searched string is not contained in my version of the file.
>>>>
>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>> file everything seems to work fine.
>>>>
>>>> Adding a dependency between my edit code and the ecore edit code
>>>> didn't work.
>>>>
>>>> Is it really necessary to do copy and paste?
>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>> delegate...
>>>
>>> public CodeGenEcoreUIPlugin() {
>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>> EcoreEditPlugin.INSTANCE,});
>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Udo
|
|
|
| Re: extending ecore classes [message #426844 is a reply to message #426818] |
Thu, 22 January 2009 12:39 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
I believe the real problem comes when you start utilizing generics, I
think one of the concerns when introducing generics is to keep the model
as compact as possible, but this introduced usage complexity. Now, with
the absence of eAnnotations in EGenericType, the annotation approach is
simply impossible.
Ed Merks wrote:
> Udo,
>
> Comments below.
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I thought about your advice using EAnnotations to get the additional
>> features into ecore.
>>
>> But I am not sure if I understood how it is supposed to do.
>>
>> I would take the original ecore model and add annotations to the
>> according classes?
> EAnnotations allow you to decorate an Ecore instance without extending
> any Ecore classes at or below EModelElement. If you look closely at
> EAnnotation itself, you can see it allow you to contain or reference
> arbitrary other EObject. In this way, if String to String properties
> are not sufficient, you can contain you own modeled data as well. You'd
> want to use GenPackage set to Initialize by Loading in that case so that
> instances of your objects will be created in the generated package.
>>
>> Thanks,
>> Udo
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Udo,
>>>
>>> Comments below.
>>>
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I want to add additional features to the ecore classes using the
>>>> decorator-pattern.
>>> Extending Ecore. I always tell people not to do that. That's what
>>> EAnnotations are for.
>>>>
>>>> A simple example would be adding a feature to EPackage.
>>>> I use my own interface and the EPackage-interface.
>>>> Create the code from genmodel.
>>>>
>>>> I can launch the plugin and create an extended version of EPackage.
>>>>
>>>> By clicking on the newly created item I get a
>>>> "MissingResourceException" because something like that
>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>
>>>> Those "resources" can be found in the "plugin.properties" file of
>>>> the edit code.
>>>> But the searched string is not contained in my version of the file.
>>>>
>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>> file everything seems to work fine.
>>>>
>>>> Adding a dependency between my edit code and the ecore edit code
>>>> didn't work.
>>>>
>>>> Is it really necessary to do copy and paste?
>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>> delegate...
>>>
>>> public CodeGenEcoreUIPlugin() {
>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>> EcoreEditPlugin.INSTANCE,});
>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Udo
|
|
|
| Re: extending ecore classes - Apology [message #426845 is a reply to message #426842] |
Thu, 22 January 2009 12:42 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Everyone, I am truly sorry about this mass resubmission, I had a problem
with me newsreader, please accept my apology
Ed Merks wrote:
> Hossam,
>
> I assume you're having problems confirming that your posts are getting
> onto the newsgroup, but there are 5 duplicates now, so rest assured they
> are showing up. I answered the first post...
>
>
> Hossam Karim wrote:
>> I believe the real problem comes when you start utilizing generics, I
>> think one of the concerns when introducing generics is to keep the model
>> as compact as possible, but this introduced usage complexity. Now, with
>> the absence of eAnnotations in EGenericType, the annotation approach is
>> simply impossible.
>> Ed Merks wrote:
>>> Udo,
>>>
>>> Comments below.
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I thought about your advice using EAnnotations to get the additional
>>>> features into ecore.
>>>>
>>>> But I am not sure if I understood how it is supposed to do.
>>>>
>>>> I would take the original ecore model and add annotations to the
>>>> according classes?
>>> EAnnotations allow you to decorate an Ecore instance without
>>> extending any Ecore classes at or below EModelElement. If you look
>>> closely at EAnnotation itself, you can see it allow you to contain or
>>> reference arbitrary other EObject. In this way, if String to String
>>> properties are not sufficient, you can contain you own modeled data
>>> as well. You'd want to use GenPackage set to Initialize by Loading
>>> in that case so that instances of your objects will be created in the
>>> generated package.
>>>>
>>>> Thanks,
>>>> Udo
>>>>
>>>>
>>>>
>>>>
>>>> Ed Merks schrieb:
>>>>> Udo,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Udo Pöhner wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I want to add additional features to the ecore classes using the
>>>>>> decorator-pattern.
>>>>> Extending Ecore. I always tell people not to do that. That's what
>>>>> EAnnotations are for.
>>>>>>
>>>>>> A simple example would be adding a feature to EPackage.
>>>>>> I use my own interface and the EPackage-interface.
>>>>>> Create the code from genmodel.
>>>>>>
>>>>>> I can launch the plugin and create an extended version of EPackage.
>>>>>>
>>>>>> By clicking on the newly created item I get a
>>>>>> "MissingResourceException" because something like that
>>>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>>>
>>>>>> Those "resources" can be found in the "plugin.properties" file of
>>>>>> the edit code.
>>>>>> But the searched string is not contained in my version of the file.
>>>>>>
>>>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>>>> file everything seems to work fine.
>>>>>>
>>>>>> Adding a dependency between my edit code and the ecore edit code
>>>>>> didn't work.
>>>>>>
>>>>>> Is it really necessary to do copy and paste?
>>>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>>>> delegate...
>>>>>
>>>>> public CodeGenEcoreUIPlugin() {
>>>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>>>> EcoreEditPlugin.INSTANCE,});
>>>>> }
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Udo
>>
>>
|
|
|
| Re: extending ecore classes [message #426847 is a reply to message #426841] |
Thu, 22 January 2009 13:12 |
Hossam Karim
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Thanks Ed and sorry again for the mass resubmission..
My point is that EGenericType particularly can't be handled as a
EModelElement. This breaks the model hierarchy and consequent derived
models. Personally, I think of generics as a model instance not part of
the root metamodel. For example, consider an M2M transformation language
or an M2T language that supports mapping or transformation inheritance,
it would have been easier to work with generic types if a 'Type' root
was introduced, but this leads to more complex hierarchy beneath to
support the full generic feature. So I think is a fair trade off, as
long as the user correctly understands the magic inside the EGenericType
and how to used in every particular situation.
Ed Merks wrote:
> Hossam,
>
> I don't think it's appropriate to decorate generics (EGenericType)
> themselves. It's a simple expression language and even Java does not
> support annotating such things. It seems to me that it will always be
> possible to annotate the model element that contains the generics rather
> than decorating the generics directly. I wonder what you're trying to
> accomplish that you found impossible?
>
>
> Hossam Karim wrote:
>> I believe the real problem comes when you start utilizing generics, I
>> think one of the concerns when introducing generics is to keep the
>> model as compact as possible, but this introduced usage complexity.
>> Now, with the absence of eAnnotations in EGenericType, the annotation
>> approach is simply impossible.
>> Ed Merks wrote:
>>> Udo,
>>>
>>> Comments below.
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I thought about your advice using EAnnotations to get the additional
>>>> features into ecore.
>>>>
>>>> But I am not sure if I understood how it is supposed to do.
>>>>
>>>> I would take the original ecore model and add annotations to the
>>>> according classes?
>>> EAnnotations allow you to decorate an Ecore instance without
>>> extending any Ecore classes at or below EModelElement. If you look
>>> closely at EAnnotation itself, you can see it allow you to contain or
>>> reference arbitrary other EObject. In this way, if String to String
>>> properties are not sufficient, you can contain you own modeled data
>>> as well. You'd want to use GenPackage set to Initialize by Loading
>>> in that case so that instances of your objects will be created in the
>>> generated package.
>>>>
>>>> Thanks,
>>>> Udo
>>>>
>>>>
>>>>
>>>>
>>>> Ed Merks schrieb:
>>>>> Udo,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Udo Pöhner wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I want to add additional features to the ecore classes using the
>>>>>> decorator-pattern.
>>>>> Extending Ecore. I always tell people not to do that. That's what
>>>>> EAnnotations are for.
>>>>>>
>>>>>> A simple example would be adding a feature to EPackage.
>>>>>> I use my own interface and the EPackage-interface.
>>>>>> Create the code from genmodel.
>>>>>>
>>>>>> I can launch the plugin and create an extended version of EPackage.
>>>>>>
>>>>>> By clicking on the newly created item I get a
>>>>>> "MissingResourceException" because something like that
>>>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>>>
>>>>>> Those "resources" can be found in the "plugin.properties" file of
>>>>>> the edit code.
>>>>>> But the searched string is not contained in my version of the file.
>>>>>>
>>>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>>>> file everything seems to work fine.
>>>>>>
>>>>>> Adding a dependency between my edit code and the ecore edit code
>>>>>> didn't work.
>>>>>>
>>>>>> Is it really necessary to do copy and paste?
>>>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>>>> delegate...
>>>>>
>>>>> public CodeGenEcoreUIPlugin() {
>>>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>>>> EcoreEditPlugin.INSTANCE,});
>>>>> }
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Udo
|
|
|
| Re: extending ecore classes [message #426849 is a reply to message #426847] |
Thu, 22 January 2009 13:37 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Hossam,
Comments below.
Hossam Karim wrote:
> Thanks Ed and sorry again for the mass resubmission..
>
>
> My point is that EGenericType particularly can't be handled as a
> EModelElement.
Yes, that was definitely the intent with explicit thought given to not
supporting annotations on it.
> This breaks the model hierarchy and consequent derived models.
I don't understand what's broken.
> Personally, I think of generics as a model instance not part of the
> root metamodel.
I don't understand this point.
> For example, consider an M2M transformation language or an M2T
> language that supports mapping or transformation inheritance, it would
> have been easier to work with generic types if a 'Type' root was
> introduced, but this leads to more complex hierarchy beneath to
> support the full generic feature.
There is EClassifier. That is the type root.
> So I think is a fair trade off, as long as the user correctly
> understands the magic inside the EGenericType and how to used in every
> particular situation.
In the end, the EGenericType stuff was intended to be mappable directly
onto Java, and while you can imagine using annotations to influence how
classes, features, and other model elements are mapped to Java, it's
hard to imagine how an annotation could help map the expression language
of generics onto anything except exactly the one-to-one mapping that is
used now...
>
>
> Ed Merks wrote:
>> Hossam,
>>
>> I don't think it's appropriate to decorate generics (EGenericType)
>> themselves. It's a simple expression language and even Java does not
>> support annotating such things. It seems to me that it will always
>> be possible to annotate the model element that contains the generics
>> rather than decorating the generics directly. I wonder what you're
>> trying to accomplish that you found impossible?
>>
>>
>> Hossam Karim wrote:
>>> I believe the real problem comes when you start utilizing generics,
>>> I think one of the concerns when introducing generics is to keep the
>>> model as compact as possible, but this introduced usage complexity.
>>> Now, with the absence of eAnnotations in EGenericType, the
>>> annotation approach is simply impossible.
>>> Ed Merks wrote:
>>>> Udo,
>>>>
>>>> Comments below.
>>>>
>>>> Udo Pöhner wrote:
>>>>> Hello,
>>>>>
>>>>> I thought about your advice using EAnnotations to get the
>>>>> additional features into ecore.
>>>>>
>>>>> But I am not sure if I understood how it is supposed to do.
>>>>>
>>>>> I would take the original ecore model and add annotations to the
>>>>> according classes?
>>>> EAnnotations allow you to decorate an Ecore instance without
>>>> extending any Ecore classes at or below EModelElement. If you look
>>>> closely at EAnnotation itself, you can see it allow you to contain
>>>> or reference arbitrary other EObject. In this way, if String to
>>>> String properties are not sufficient, you can contain you own
>>>> modeled data as well. You'd want to use GenPackage set to
>>>> Initialize by Loading in that case so that instances of your
>>>> objects will be created in the generated package.
>>>>>
>>>>> Thanks,
>>>>> Udo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Udo,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>>
>>>>>> Udo Pöhner wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I want to add additional features to the ecore classes using the
>>>>>>> decorator-pattern.
>>>>>> Extending Ecore. I always tell people not to do that. That's
>>>>>> what EAnnotations are for.
>>>>>>>
>>>>>>> A simple example would be adding a feature to EPackage.
>>>>>>> I use my own interface and the EPackage-interface.
>>>>>>> Create the code from genmodel.
>>>>>>>
>>>>>>> I can launch the plugin and create an extended version of EPackage.
>>>>>>>
>>>>>>> By clicking on the newly created item I get a
>>>>>>> "MissingResourceException" because something like that
>>>>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>>>>
>>>>>>> Those "resources" can be found in the "plugin.properties" file
>>>>>>> of the edit code.
>>>>>>> But the searched string is not contained in my version of the file.
>>>>>>>
>>>>>>> Copying lines from the ecore edit code into my
>>>>>>> "plugin.properties" file everything seems to work fine.
>>>>>>>
>>>>>>> Adding a dependency between my edit code and the ecore edit
>>>>>>> code didn't work.
>>>>>>>
>>>>>>> Is it really necessary to do copy and paste?
>>>>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>>>>> delegate...
>>>>>>
>>>>>> public CodeGenEcoreUIPlugin() {
>>>>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>>>>> EcoreEditPlugin.INSTANCE,});
>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Udo
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: extending ecore classes [message #426851 is a reply to message #426818] |
Thu, 22 January 2009 14:26 |
| Eclipse User |
|
|
|
Originally posted by: udo.poehner.freenet.de
Hello,
I am still not sure if (or how) I can use EAnnotation in my project.
It looks to me like one should use EAnnotation to get functionality into
a certain model via decorating the Ecore instances with the annotation?
But I think this approach maybe not general enough for my purpose.
Because it is of academic interest I want to make Ecore itself versionable.
To achieve this I have to use the "Ecore.ecore" file and annotate every
necessary part?
I am afraid that will be a lot of work to get this working again.
Wouldn't it be easier using the decorator-pattern?
Thanks,
Udo
Ed Merks schrieb:
> Udo,
>
> Comments below.
>
> Udo Pöhner wrote:
>> Hello,
>>
>> I thought about your advice using EAnnotations to get the additional
>> features into ecore.
>>
>> But I am not sure if I understood how it is supposed to do.
>>
>> I would take the original ecore model and add annotations to the
>> according classes?
> EAnnotations allow you to decorate an Ecore instance without extending
> any Ecore classes at or below EModelElement. If you look closely at
> EAnnotation itself, you can see it allow you to contain or reference
> arbitrary other EObject. In this way, if String to String properties
> are not sufficient, you can contain you own modeled data as well. You'd
> want to use GenPackage set to Initialize by Loading in that case so that
> instances of your objects will be created in the generated package.
>>
>> Thanks,
>> Udo
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Udo,
>>>
>>> Comments below.
>>>
>>>
>>> Udo Pöhner wrote:
>>>> Hello,
>>>>
>>>> I want to add additional features to the ecore classes using the
>>>> decorator-pattern.
>>> Extending Ecore. I always tell people not to do that. That's what
>>> EAnnotations are for.
>>>>
>>>> A simple example would be adding a feature to EPackage.
>>>> I use my own interface and the EPackage-interface.
>>>> Create the code from genmodel.
>>>>
>>>> I can launch the plugin and create an extended version of EPackage.
>>>>
>>>> By clicking on the newly created item I get a
>>>> "MissingResourceException" because something like that
>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>
>>>> Those "resources" can be found in the "plugin.properties" file of
>>>> the edit code.
>>>> But the searched string is not contained in my version of the file.
>>>>
>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>> file everything seems to work fine.
>>>>
>>>> Adding a dependency between my edit code and the ecore edit code
>>>> didn't work.
>>>>
>>>> Is it really necessary to do copy and paste?
>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>> delegate...
>>>
>>> public CodeGenEcoreUIPlugin() {
>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>> EcoreEditPlugin.INSTANCE,});
>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Udo
|
|
|
| Re: extending ecore classes [message #426852 is a reply to message #426851] |
Thu, 22 January 2009 14:29 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Udo,
Comments below.
Udo Pöhner wrote:
> Hello,
>
> I am still not sure if (or how) I can use EAnnotation in my project.
And I'm not sure what you're trying to accomplish.
>
> It looks to me like one should use EAnnotation to get functionality
> into a certain model via decorating the Ecore instances with the
> annotation?
Absolutely.
>
> But I think this approach maybe not general enough for my purpose.
I doubt that given that you can via an annotation contain anything.
> Because it is of academic interest I want to make Ecore itself
> versionable.
Not sure what's implied by versionable...
>
> To achieve this I have to use the "Ecore.ecore" file and annotate
> every necessary part?
You annotate your own models, not the Ecore itself because that's
already generated and you can't change it.
> I am afraid that will be a lot of work to get this working again.
> Wouldn't it be easier using the decorator-pattern?
EAnnotations are for decorating Ecore models...
>
> Thanks,
> Udo
>
>
>
>
>
>
> Ed Merks schrieb:
>> Udo,
>>
>> Comments below.
>>
>> Udo Pöhner wrote:
>>> Hello,
>>>
>>> I thought about your advice using EAnnotations to get the additional
>>> features into ecore.
>>>
>>> But I am not sure if I understood how it is supposed to do.
>>>
>>> I would take the original ecore model and add annotations to the
>>> according classes?
>> EAnnotations allow you to decorate an Ecore instance without
>> extending any Ecore classes at or below EModelElement. If you look
>> closely at EAnnotation itself, you can see it allow you to contain or
>> reference arbitrary other EObject. In this way, if String to String
>> properties are not sufficient, you can contain you own modeled data
>> as well. You'd want to use GenPackage set to Initialize by Loading
>> in that case so that instances of your objects will be created in the
>> generated package.
>>>
>>> Thanks,
>>> Udo
>>>
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Udo,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Udo Pöhner wrote:
>>>>> Hello,
>>>>>
>>>>> I want to add additional features to the ecore classes using the
>>>>> decorator-pattern.
>>>> Extending Ecore. I always tell people not to do that. That's what
>>>> EAnnotations are for.
>>>>>
>>>>> A simple example would be adding a feature to EPackage.
>>>>> I use my own interface and the EPackage-interface.
>>>>> Create the code from genmodel.
>>>>>
>>>>> I can launch the plugin and create an extended version of EPackage.
>>>>>
>>>>> By clicking on the newly created item I get a
>>>>> "MissingResourceException" because something like that
>>>>> "_UI_EClassifier_ePackage_feature" is not found.
>>>>>
>>>>> Those "resources" can be found in the "plugin.properties" file of
>>>>> the edit code.
>>>>> But the searched string is not contained in my version of the file.
>>>>>
>>>>> Copying lines from the ecore edit code into my "plugin.properties"
>>>>> file everything seems to work fine.
>>>>>
>>>>> Adding a dependency between my edit code and the ecore edit code
>>>>> didn't work.
>>>>>
>>>>> Is it really necessary to do copy and paste?
>>>> Maybe the plugin class just needs to specify EcoreEditPlugin as a
>>>> delegate...
>>>>
>>>> public CodeGenEcoreUIPlugin() {
>>>> super(new ResourceLocator[]{GenModelEditPlugin.INSTANCE,
>>>> EcoreEditPlugin.INSTANCE,});
>>>> }
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Udo
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 13:28:01 GMT 2024
Powered by FUDForum. Page generated in 0.05064 seconds |
] 
Search
Help
Register
Login
Home
