Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Generating an ecore editor (besides the existing one)
Generating an ecore editor (besides the existing one) [message #418313] Fri, 11 April 2008 15:41 Go to next message
Eclipse UserFriend
Originally posted by: thomas.ternite.tu-clausthal.de

Hello there,

I have some difficulties using EMF. When trying the tutorials,
everything works quite fine. The examples are restricted to minimal
samples (which is OK for tutorials, really!).


Then I wanted EMF to generate an editor for a larger model.


Two tries:
1. I tried to generate an editor for UML (I know there already is one,
but I want to understand EMF and ecore, so there is need to play around).

I was successful with this, though I ran into some problems. Anyone
interested in the problems and my solutions may read my descriptions at
the end of this message.


2. I tried to generate an editor for ecore (using Ecore.ecore). That is
why I write to this newsgroup, hoping for some hints.

I looked for Ecore.ecore and finally found it in the plugin folder in
org.eclipse.emf.ecore_2.3.2.v200802051830.jar. I placed a copy into my
workspace, then let EMF generate an Ecore.genmodel. Then, I generated
Code ('Generate All' on the genmodel).

Now my problems with the generated code:
* A problem resides in EObjectImpl.java. There are only two methods
generated, namely the constructor and eStaticClass(). There are lots
of methods declared in the interface file EObject.java, though. Why
doesn't EMF generate these methods in the implementation class?
* This isn't the only class with such a problem. In fact, all interface
classes can correctly be compiled, but most implementation classes
contain errors.

Any ideas? Do you need more input? I'm using Eclipse 3.3.2 and EMF 2.3.2.
Am I wrong in my understanding that theoretically I should be able to
generate an ecore editor with ecore.ecore?

Thomas.





First try (generating a UML editor):

I looked for UML.ecore and found it in the plugin folder in
org.eclipse.uml2.uml_2.1.1.v200707311200.jar. I placed a copy into my
workspace, then let EMF generate a UML.genmodel. Using this, I generated
Code ('Generate All'). I wanted to generate an editor to be able to edit
UML-Diagrams (for sandbox purposes, playing around, learning about EMF
and its possiblities, you know...).

At first I had lots of duplicate methods in the interfaces. By looking
into UML.ecore, I found out, that for some Properties there where given
explicitly get-/set-Methods. Removing them circumvented this error.
Since EMF automatically generates getters/setters, these where defined
redundandly.
Then there was one method called "break", which irritated the java
compiler who thought this to be the key word "break". Renaming this
method in "break2" solved that problem.
After that, EMF generated code that could be compiled and run.

I soon found out that I had to rename the model from 'uml' to 'myuml'
(i.e. anything different from 'uml') to circumvent the generated editor
to use the wrong model editor plugin. Without renaming, I was able to
generate an editor, but that editor did use the UML plugin that was
already installed in eclipse, not my "own" uml plugin to edit a new
model. Renaming solved that problem, too.

Now I have successfully compiled a UML editor using EMF. Thanks for that
to the developers. ;o)))
Re: Generating an ecore editor (besides the existing one) [message #418316 is a reply to message #418313] Fri, 11 April 2008 16:34 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Thomas,

Comments below.


Thomas Ternité wrote:
> Hello there,
>
> I have some difficulties using EMF. When trying the tutorials,
> everything works quite fine. The examples are restricted to minimal
> samples (which is OK for tutorials, really!).
>
>
> Then I wanted EMF to generate an editor for a larger model.
>
>
> Two tries:
> 1. I tried to generate an editor for UML (I know there already is one,
> but I want to understand EMF and ecore, so there is need to play around).
>
> I was successful with this, though I ran into some problems. Anyone
> interested in the problems and my solutions may read my descriptions
> at the end of this message.
>
>
> 2. I tried to generate an editor for ecore (using Ecore.ecore). That
> is why I write to this newsgroup, hoping for some hints.
>
> I looked for Ecore.ecore and finally found it in the plugin folder in
> org.eclipse.emf.ecore_2.3.2.v200802051830.jar. I placed a copy into my
> workspace, then let EMF generate an Ecore.genmodel. Then, I generated
> Code ('Generate All' on the genmodel).
>
> Now my problems with the generated code:
> * A problem resides in EObjectImpl.java. There are only two methods
> generated, namely the constructor and eStaticClass(). There are lots
> of methods declared in the interface file EObject.java, though. Why
> doesn't EMF generate these methods in the implementation class?
You're trying to regenerate the Ecore model itself from scratch? We
regenerate Ecore regularly without any problems, but the key is we
regenerate. There are lots of places we need to implement the derived
methods properly, and EObject itself is very special being the root of
everything. It doesn't seem a useful exercise to generate Ecore from
scratch...
> * This isn't the only class with such a problem. In fact, all interface
> classes can correctly be compiled, but most implementation classes
> contain errors.
I imagine there will be significant confusion over the version of Ecore
in the EMF plugins verses a copy that you've generated with conflicting
package names. Again, I don't see this as a useful exercise...
>
> Any ideas? Do you need more input? I'm using Eclipse 3.3.2 and EMF 2.3.2.
Why would you generate the model though.
> Am I wrong in my understanding that theoretically I should be able to
> generate an ecore editor with ecore.ecore?
Yes, you should be able to generate an editor (although there obviously
is one already) but to generate the core bootstrapped metamodel itself
from scratch is kind of weird.
>
> Thomas.
>
>
>
>
>
> First try (generating a UML editor):
>
> I looked for UML.ecore and found it in the plugin folder in
> org.eclipse.uml2.uml_2.1.1.v200707311200.jar. I placed a copy into my
> workspace, then let EMF generate a UML.genmodel. Using this, I
> generated Code ('Generate All'). I wanted to generate an editor to be
> able to edit UML-Diagrams (for sandbox purposes, playing around,
> learning about EMF and its possiblities, you know...).
You could just invoke Generate Editor.
>
> At first I had lots of duplicate methods in the interfaces. By looking
> into UML.ecore, I found out, that for some Properties there where
> given explicitly get-/set-Methods. Removing them circumvented this
> error. Since EMF automatically generates getters/setters, these where
> defined redundandly.
Note also that UML itself is generated with an extended GenModel
implemented in the UML project, so you'd want to reuse the UML.genmodel
that's in the existing project.
> Then there was one method called "break", which irritated the java
> compiler who thought this to be the key word "break". Renaming this
> method in "break2" solved that problem.
> After that, EMF generated code that could be compiled and run.
The UML GenModel must handle colliding method names; EMF expects you to
avoid them.
>
> I soon found out that I had to rename the model from 'uml' to 'myuml'
> (i.e. anything different from 'uml') to circumvent the generated
> editor to use the wrong model editor plugin. Without renaming, I was
> able to generate an editor, but that editor did use the UML plugin
> that was already installed in eclipse, not my "own" uml plugin to edit
> a new model. Renaming solved that problem, too.
To get a functional UML model to a lot of hand coding, so while an
interesting exercise, it's sort of pointless as well.
>
> Now I have successfully compiled a UML editor using EMF. Thanks for
> that to the developers. ;o)))
>
Don't you have a nice big model of your own you can pick on? :-P


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Generating an ecore editor (besides the existing one) [message #418331 is a reply to message #418316] Sun, 13 April 2008 14:54 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: thomas.ternite.tu-clausthal.de

Thanks for your answer, Ed!

Ed Merks schrieb:
> You're trying to regenerate the Ecore model itself from scratch?

yes, as a lecture.

> Yes, you should be able to generate an editor (although there obviously
> is one already) but to generate the core bootstrapped metamodel itself
> from scratch is kind of weird.

You're right, it may appear weird, since there already is an editor.

But I am looking for a (standard) metamodel that I can use to build
models containing classes, associations, properties etc.

I thought of UML Class Diagrams, MOF, or Ecore.

The point is: I'm working at Clausthal University of Technology. My
research field is enabling models to support variability. I think it
might be worth a try to take a standard metamodel and extend it with
variability aspects to be able to build models that contain originary
model contents (like classes, associations) along with variability
information.

I want to extend a metamodel for that purpose. I thought about giving
EMF a try, since I can use it to define the metamodel and then generate
an editor for that metamodel. At the moment, I am looking for the right
technology to be used in a prototype.

I assume that it would be worth a try to extend UML using EMF.

>> Then there was one method called "break", which irritated the java
>> compiler who thought this to be the key word "break". Renaming this
>> method in "break2" solved that problem.
>> After that, EMF generated code that could be compiled and run.
> The UML GenModel must handle colliding method names; EMF expects you to
> avoid them.

I see. Obviously, I underestimated the possibilities (and liabilities)
coming with changing the genmodel. I thought you always let EMF generate
the genmodel from an ecore file. I thought I only could do some fine
tuning with a genmodel.

A question: if you take a previously generated, but then further
developed genmodel for UML and even for ecore, how do you keep the
..ecore-model and the genmodel consistent when the .ecore-model develops?

>> I soon found out that I had to rename the model from 'uml' to 'myuml'
>> (i.e. anything different from 'uml') to circumvent the generated
>> editor to use the wrong model editor plugin. Without renaming, I was
>> able to generate an editor, but that editor did use the UML plugin
>> that was already installed in eclipse, not my "own" uml plugin to edit
>> a new model. Renaming solved that problem, too.
> To get a functional UML model to a lot of hand coding, so while an
> interesting exercise, it's sort of pointless as well.

Might be pointless, unless you intend to play around with the metamodel,
inserting some minor changes to be able to see their effect, right?

I found that the UML-genmodel that is supplied in the plugin-files
generates duplicate methods, too. I don't understand that.

>> Now I have successfully compiled a UML editor using EMF. Thanks for
>> that to the developers. ;o)))
>>
> Don't you have a nice big model of your own you can pick on? :-P

I have, but unfortunately it isn't in ecore-format yet. I wanted to
learn about the possibilities of EMF/ecore before beginning the
transformation.

Furthermore, that metamodel is itself only a model of UML Class diagram.
I want to enhance it's metamodel to add variability possibilities to my
model.

Thomas.
Re: Generating an ecore editor (besides the existing one) [message #418332 is a reply to message #418331] Sun, 13 April 2008 15:36 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Thomas,

Comments below.

Thomas Ternité wrote:
> Thanks for your answer, Ed!
>
> Ed Merks schrieb:
>> You're trying to regenerate the Ecore model itself from scratch?
>
> yes, as a lecture.
It's kind of a lesson in bootstrapping...
>
>> Yes, you should be able to generate an editor (although there
>> obviously is one already) but to generate the core bootstrapped
>> metamodel itself from scratch is kind of weird.
>
> You're right, it may appear weird, since there already is an editor.
>
> But I am looking for a (standard) metamodel that I can use to build
> models containing classes, associations, properties etc.
>
> I thought of UML Class Diagrams, MOF, or Ecore.
Perhaps EMOF itself might be an interesting exercise...
>
> The point is: I'm working at Clausthal University of Technology. My
> research field is enabling models to support variability. I think it
> might be worth a try to take a standard metamodel and extend it with
> variability aspects to be able to build models that contain originary
> model contents (like classes, associations) along with variability
> information.
Sounds a bit related to http://gsd.uwaterloo.ca/projects/fmp-plugin/
>
> I want to extend a metamodel for that purpose. I thought about giving
> EMF a try, since I can use it to define the metamodel and then
> generate an editor for that metamodel. At the moment, I am looking for
> the right technology to be used in a prototype.
>
> I assume that it would be worth a try to extend UML using EMF.
I know in the UML newsgroup I've often seen talk about light weight and
heavy weight extensions, there the first is about using profiles and the
latter is about actually extending the classes of the model. In general
I always advise against extending Ecore, not so much because it's wrong
or evil, but because I don't guarantee binary compatibility for the
implementation class and other tools, like importing to Ecore will of
course always create instance of Ecore, not instances of some other
derived model, so an extended model is just tricky to make work in as
many places. So even for Ecore, I typically recommend using
EAnnotations to add additional information...
>
>>> Then there was one method called "break", which irritated the java
>>> compiler who thought this to be the key word "break". Renaming this
>>> method in "break2" solved that problem.
>>> After that, EMF generated code that could be compiled and run.
>> The UML GenModel must handle colliding method names; EMF expects you
>> to avoid them.
>
> I see. Obviously, I underestimated the possibilities (and liabilities)
> coming with changing the genmodel. I thought you always let EMF
> generate the genmodel from an ecore file. I thought I only could do
> some fine tuning with a genmodel.
That's basically true, but once generated, it retains important
information that's preserved when you reconcile it with a newer version
of the Ecore model. If you want to extend UML, you should use it's
existing GenModel directly and likely need your extension model to be
using UML's extended GenModel.
>
> A question: if you take a previously generated, but then further
> developed genmodel for UML and even for ecore, how do you keep the
> ..ecore-model and the genmodel consistent when the .ecore-model develops?
Yes, there is a reconciliation process. If the model comes from another
source, e.g., UML is described with UML, you'd repeat the import steps.
If you modify the Ecore directly, the reconciliation happens on the
fly. So the GenModel is a decorator that preserves information as the
underlying Ecore model evolves.
>
>>> I soon found out that I had to rename the model from 'uml' to
>>> 'myuml' (i.e. anything different from 'uml') to circumvent the
>>> generated editor to use the wrong model editor plugin. Without
>>> renaming, I was able to generate an editor, but that editor did use
>>> the UML plugin that was already installed in eclipse, not my "own"
>>> uml plugin to edit a new model. Renaming solved that problem, too.
>> To get a functional UML model to a lot of hand coding, so while an
>> interesting exercise, it's sort of pointless as well.
>
> Might be pointless, unless you intend to play around with the
> metamodel, inserting some minor changes to be able to see their
> effect, right?
Fun and games. :-)
>
> I found that the UML-genmodel that is supplied in the plugin-files
> generates duplicate methods, too. I don't understand that.
You could ask about that on the UML2 newsgroup. There might be some
issues that don't show up when you regenerate but would show up if you
generated from scratch. The UML folks might be concerned about those
and just never noticed...
>
>>> Now I have successfully compiled a UML editor using EMF. Thanks for
>>> that to the developers. ;o)))
>>>
>> Don't you have a nice big model of your own you can pick on? :-P
>
> I have, but unfortunately it isn't in ecore-format yet. I wanted to
> learn about the possibilities of EMF/ecore before beginning the
> transformation.
What form is it in? Having more "whatever" to Ecore converters is
always interesting, especially given we already have two way conversion
between Ecore, EMOF, UML, XML Schema, and annotated Java thereby making
all these forms interchangeable. Like a hub-and-spoke airport design,
adding just one more spoke makes a lot of different trips possible...
>
> Furthermore, that metamodel is itself only a model of UML Class
> diagram. I want to enhance it's metamodel to add variability
> possibilities to my model.
Sounds cool. I'll do what I can help answer questions.
>
> Thomas.


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:[Announcement] Eclipse/OMG Symposium at the OMG Technical Meeting in Ottawa
Next Topic:Eclipse 3.4/emf 2.4
Goto Forum:
  


Current Time: Thu Mar 28 21:57:43 GMT 2024

Powered by FUDForum. Page generated in 0.03425 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top