Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » Best practice
Best practice [message #186244] Mon, 12 May 2008 08:15 Go to next message
paolo russian is currently offline paolo russianFriend
Messages: 34
Registered: July 2009
Member
Hello! I'm testing the exp.SDK functionality in preserving the visualID
when messing randomly around with the models, and regenerating. Since I
have to handle a very large model with really a lot of custom code already
in the .diagram I wonder what is the best way, or the way GMF is meant to
work, in regenerating the model.
I mean: when I want to add a new item to the custom palette, or
adding/removing/modify widget's propertiy-sheet fields, am I supposed to
edit the gmfgen only? Or the gmfmap, ecore tool and graph together and
regenerate the gmfgen? Or have I got to regenerate also the gmfmap (this
way you lose all the customizations on the gmfmap!!)?
Afaik to add a property to a eobject, it's mandatory to add it to the
ecore, then you've to regenerate the genmodel.. so one is forced to
re-combine ecore+tool+graph together to a newer gmfmap and this way you
lose every customization you did on the gmfmap (for example you have to
manually re-enter all the "Feature Label Mapping false" to each node or
the validator won't proceed further.. and this is unacceptable when you
have a gmfmap with 30-35 top node references.
That's why I wonder if there is a best practice I should apply when I want
to add a new widget or modify a previous one without messing the whole
thing up.
Thanks a lot for any suggestion on this.

Paolo Russian
Re: Best practice [message #186321 is a reply to message #186244] Mon, 12 May 2008 11:20 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Paolo,

Standard use case is:
- create .gmfmap, .gmftool, .gmfgraph
- generate .gmfgen
- generate diagram code

- modify .ecore, .gmfmap, .gmftool, .gmfgraph
- regenerate .gmfgen
- regenerate code

There is an additional plugin (org.eclipse.gmf.bridge.trace) solving most
of the problems with VisualID on .gmfgen regeneration.

-----------------
Alex Shatalin
Re: Best practice [message #186337 is a reply to message #186321] Mon, 12 May 2008 11:32 Go to previous messageGo to next message
paolo russian is currently offline paolo russianFriend
Messages: 34
Registered: July 2009
Member
thanks alex, in facts that's what I successfully do with my dummy
model-diagram editor plugin I did for my experiments prior to blow up the
real enterprise model.
I have that trace plugin and in my simple thin-to-the-bone model I can
draw my diagram, save them, then add a new widget in the plugin,
regenerate everything like you said, and I can open the saved diagram
without any error, that's really amazing! That's to say I can do it, in
some way.

While I experience lotsa trouble when trying the same process on the
enterprise model, even if I regenerate the code or re-derive something
without editing anything... I get dozens-thousands of errors "literals not
resolved".. "editparts missing", in other words, as soon as I touch the
tinyest thing the workspace recompiles and everything is messed so much I
have to delete all the workspace files and repaste them from a backup or
svn.

And aren't you gonna lose the customizations made to the mapping model if
you regenerate it as you said? How can I preserve the tree-node structure
of the actual model avoiding to add all those "feature label mappings" to
the nodes?

Thanks again for your precious reply above.
Re: Best practice [message #186345 is a reply to message #186321] Mon, 12 May 2008 11:54 Go to previous messageGo to next message
paolo russian is currently offline paolo russianFriend
Messages: 34
Registered: July 2009
Member
sorry for doubleposting, but please correct me if I'm wrong somewhere:

1) design, generate everything until you have your custom palette plugin
up and running
2) do your overrides and customizations on the generated code keeping in
mind to put the "generated not" wherever you edit the generated code.

------

3) modify the .ecore, adding a new eobject, adjusting the containments etc.
3b) delete or rename the old genmodel
3c)re-derive the .genmodel (what if I have 2 models together, one
externally referenced instead of a normal all-in-one?)
3d)right-click the genmodel and regenerate the Model code and the Edit
code (or simply "All").

-- I already get error on this 3c passage --

4) add the new widget's creation tool in the palette, under gmftool model

5) add and setup the new widget look under the gmfgraph model

6) delete the gmfmap file or rename it
6b)combine ecore+tool+graph merging to a new mapping model
6c)manually reconfigure all of the mapping model, since the derived one is
never what you need (in my test, I know I may be very noob)

7) delete the gmfgen or rename it

8) generate the gmfgen file from the gmfmap
9) right click on the gmfgen and "generate diagram code"
10)on the gmf dashboard, "generate diagram editor"

-- finished, launch your plugin or pack it into a jar --

I tried to make it detailed because maybe I'm wrong right in the process.

P.
Re: Best practice [message #186371 is a reply to message #186337] Mon, 12 May 2008 12:08 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Paolo,

> without editing anything... I get dozens-thousands of errors "literals
> not resolved".. "editparts missing", in other words, as soon as I
This can be a problem of GMF. Can you please try to locate error-prone parts
of your model?

> And aren't you gonna lose the customizations made to the mapping model
> if you regenerate it as you said? How can I preserve the tree-node
No, you should not loos anything in .gmfmap model because I'm suggesting
you to edit directly .gmfmap model (without any additional wizards). So,
just modify your .gmfmap model in accordance with .ecore and regenerate .gmfgen
+ code.

-----------------
Alex Shatalin
Re: Best practice [message #186378 is a reply to message #186345] Mon, 12 May 2008 12:11 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Paolo,

> 3b) delete or rename the old genmodel
Do not remove it - just call genrate action - new .gmfgen model will be merget
with old model contents to preserve some possible customized values from
your old .gmfgen model.

> 6) delete the gmfmap file or rename it
Do not delete exisitng .gmfmap file - just modify it instead to reflect recent
changes in .ecore model..

> 7) delete the gmfgen or rename it
Again, do not touch .gmfgen model here. ;-)

-----------------
Alex Shatalin
Re: Best practice [message #186384 is a reply to message #186378] Mon, 12 May 2008 12:19 Go to previous messageGo to next message
paolo russian is currently offline paolo russianFriend
Messages: 34
Registered: July 2009
Member
sometimes you cannot! Can't remember by heart wich one of the three but
one for sure bugs you if you try to regenerate with the same name ...
"file already exists" I think it's the genmodel.

Regarding the regeneration process.. wait, working "with" the gmfmap
implies that you do not delete it. The ecore and the tooling/graphical
defs included in the .map are phisically linked with the real
counterparts? (I mean: modify linked .ecore and real ecore gets modified
as well and vice-versa?).
Before you said to modify the .ecore the tool the graph and to re-merge
in to .map, this looks different as approach!

Forgive my confusion :)
Re: Best practice [message #186400 is a reply to message #186384] Mon, 12 May 2008 12:45 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Paolo,

> ... "file already exists" I think it's the genmodel.
This is a warning. you can ignore it and should ignore it if you are intentionally
regenerating .gmfmap file.

> implies that you do not delete it. The ecore and the tooling/graphical
> defs included in the .map are phisically linked with the real
> counterparts? (I mean: modify linked .ecore and real ecore gets
Corresponding elements of .ecore, .gmftool, .gmfgraph are referenced from
..gmfmap model - references stored using EMF, so if you add new
attribute to existing EClass this attribute will be available in .gmfmap..

> Before you said to modify the .ecore the tool the graph and to
> re-merge in to .map, this looks different as approach!
Do not see the differences. Example:
- Add new EClass to your .ecore model -> open .gmfmap and add new mapping
there.

If you are talking about more complicated situations like: EClass is renamed
in .ecore model. Then you should perform some "refactoring" because .ecore
elements are referenced from .gmfmap file using their names, so if you modify
..ecore file to make corresponding name not resolvable (just rename referenced
EClass/EAttribute) then you'll not be able to open .gmfmap file - you'll
see error page instead.

To work arounf this problem I suggest you to perform all the modifications
of your .ecore model in .gmfmap editor. If you open .gmfmap editor and brows
it's element then referened .ecore file will be loaded there. If you perform
any modifications on the used .ecore file in .gmfmap editor and save it then
EMF will refactor .gmfmap file for you and persist new (changed) name of
modified .ecore element instead of old one. This should help in case of complex
domain model refactorings.

BTW, still can not completely understand use case you are working on. Can
you please try to re-explain in step by step if I did not answer your question
yet.

-----------------
Alex Shatalin
Re: Best practice [message #186407 is a reply to message #186378] Mon, 12 May 2008 12:47 Go to previous messageGo to next message
paolo russian is currently offline paolo russianFriend
Messages: 34
Registered: July 2009
Member
I face this same issue:
http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/m sg00330.html

may be this that produces my problems or it's just a minor detail?
Re: Best practice [message #186414 is a reply to message #186371] Mon, 12 May 2008 12:59 Go to previous messageGo to next message
paolo russian is currently offline paolo russianFriend
Messages: 34
Registered: July 2009
Member
>> without editing anything... I get dozens-thousands of errors "literals
>> not resolved".. "editparts missing", in other words, as soon as I
> This can be a problem of GMF. Can you please try to locate error-prone parts
> of your model?

---
> Alex Shatalin

it's difficult since this model I have to handle it's cross referenced,
got multiple ecore models instead of one only (one for example only for
custom data type definition), but my problems seems to raise when I delete
the genmodel file and I derive it again. I get errors from code portions I
do not touch and that have nothing to do with what I've modified, blowin
as soon I "generate model code".

errors looks like this:
Severity and Description Path Resource Location Creation Time Id
components.XXX cannot be resolved to a
type GUI_Designer.diagram/src/components/diagram/part ComponentsDiagramUpdater.java line
1466 1210596393015 57819
components.XXX cannot be resolved to a
type GUI_Designer.diagram/src/components/diagram/part ComponentsDiagramUpdater.java line
1466 1210596393015 57820
Messages.DataGridColumn15CreationTool_desc cannot be
resolved GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
531 1210596392734 57664
Messages.DataGridColumn15CreationTool_title cannot be
resolved GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
530 1210596392734 57663
Messages.TextBox14CreationTool_desc cannot be
resolved GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
512 1210596392734 57662
Messages.TextBox14CreationTool_title cannot be
resolved GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
511 1210596392734 57661
The method createButton2CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
43 1210596392734 57566
The method createCheckBox3CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
44 1210596392734 57567
The method createComboBox4CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
45 1210596392734 57568
The method createDataGrid5CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
46 1210596392734 57569
The method createDateTimePicker6CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
47 1210596392734 57570
The method createGroupBox7CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
48 1210596392734 57571
The method createGroupCheckBox20CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
61 1210596392734 57582
The method createHidden18CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
59 1210596392734 57580
The method createLink19CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
60 1210596392734 57581
The method createListBox8CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
49 1210596392734 57572
The method createListView9CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
50 1210596392734 57573
The method createMonthCalendar10CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
51 1210596392734 57574
The method createPassword17CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
58 1210596392734 57579
The method createPictureBox11CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
52 1210596392734 57575
The method createRadioButton13CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
54 1210596392734 57577
The method createRadioGroup12CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
53 1210596392734 57576
The method createTextArea16CreationTool() is undefined for the type
ComponentsPaletteFactory GUI_Designer.diagram/src/components/diagram/part ComponentsPaletteFactory.java line
57 1210596392734 57578
The method getEditor_XXX() is undefined for the type
ComponentsPackage GUI_Designer.diagram/src/components/diagram/edit/policies EditorCanonicalEditPolicy.java line
154 1210596393859 58288
The method getEditor_XXX() is undefined for the type
ComponentsPackage GUI_Designer.diagram/src/components/diagram/edit/policies EditorItemSemanticEditPolicy.java line
67 1210596393859 58277
The method getXXX_Value() is undefined for the type
ComponentsPackage GUI_Designer.diagram/src/components/diagram/providers ComponentsParserProvider.java line
162 1210596392484 57331
The method getXXX() is undefined for the type
ComponentsPackage GUI_Designer.diagram/src/components/diagram/part ComponentsDomainModelElementTester.java line
84 1210596392796 57672
The method getXXX() is undefined for the type
ComponentsPackage GUI_Designer.diagram/src/components/diagram/part ComponentsVisualIDRegistry.java line
621 1210596392687 57565
The method getXXX() is undefined for the type
ComponentsPackage GUI_Designer.diagram/src/components/diagram/providers ComponentsElementTypes.java line
666 1210596392593 57439
The method getXXX() is undefined for the type
Editor GUI_Designer.diagram/src/components/diagram/part ComponentsDiagramUpdater.java line
1465 1210596393015 57818
Re: Best practice [message #186422 is a reply to message #186400] Mon, 12 May 2008 13:11 Go to previous messageGo to next message
paolo russian is currently offline paolo russianFriend
Messages: 34
Registered: July 2009
Member
Ok I'll try to make me clear :)

To regenerate the gmfGEN file with a new widget on my palette, I must add
all the various node around in the models, and I got this. But when I
right click the gmfMAP file to "create generator model" after some
[next->] button presses the wizard stops everything since it recognizes
that the .genmodel file does not contain the new eObject thingies (error
is Can't find genClass for class in package components) and you can only
cick on "cancel", so no gmfGEN created yet.

Then looks to me I'm requested to update the genmodel file, so I open up
the gmf dashboard and click on "derive" button near the ecore. Again, it
stops me because another "components.genmodel" already exists and the only
option is "cancel" (maybe this is a bug, since you believe it behaves
differently!). So I rename the old genmodel, derive the fresh one, and
finally I can generate the gmfGEN.

No errors yet, but when I right click the gmfGEN file to "generate diagram
code" errors start to rise, just a few perhaps.. but not related to what
I've edited.
So I think I need to regenerate also the model code and the edit code from
the genmodel file (don't I? don't know!) and as I do this... *bang*
thousands of errors. (classes not found, missing references... and
dupliate entries for thing I never touched!!)
Re: Best practice [message #186429 is a reply to message #186407] Mon, 12 May 2008 14:05 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Paolo,

This thread AFAIU is about EMF .genmodel file update. Once you change .ecore
file you have to invoke "Reload..." popup menu action for the corresponding
..genmodel file before continue referencing it from the GMF .gmfgen model
(.gmfmap model reference .ecore elements only).

-----------------
Alex Shatalin
Re: Best practice [message #186437 is a reply to message #186422] Mon, 12 May 2008 14:09 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Paolo,

> thingies (error is Can't find genClass for class in package
> components) and you can only cick on "cancel", so no gmfGEN created
Try calling EMF "Reload..." acton for .genmodel file - looks like the reason
is in modified .ecore model and stale .genmodel for it...
In addition to make GMF-generated code compilable you probably have to regenerate
code for your EMF model.

-----------------
Alex Shatalin
Re: Best practice [message #186462 is a reply to message #186437] Mon, 12 May 2008 15:40 Go to previous messageGo to next message
paolo russian is currently offline paolo russianFriend
Messages: 34
Registered: July 2009
Member
I did it, thanks for your effort. I'm not very sure what the problem was
on my really humble opinion may be one of these (maybe someone smarter
than me in gmf can write some tiny doc about it):

a) the gmf plugin may have some minor bug that behave different if
refreshing from the .genmodel file or refreshing the genmodel IN the
gmfGEN wizard.

b) I was regenerating code in a wrong order. I still don't know if there
is a real order in this...

c) My model is so damn complicated that my previous trials were made using
the same custom Edata types.. which could have driven me into lotsa
errors. Now I've tried with a common Ereference XXX and a WhateverValue as
a single child property.

but my favourite culpirit should be:

d) My generated code has a impressive amount of customization (generated
not tags wherever), some of them were on a manual visualID setting, to fix
the compatibility in our previous release. I removed this "not" tag
letting the gmf to take care of shaking everything again.. and this fixed
a big part of errors. From thousand then I got only 19 errors.
Secondly, and this was a hard one to find... A lot of missing references
derived from another "genated not" bunch of tags placed in the java code
where the widget icons and icon-groups are placed on the palette. Since I
have 4 groups of widgets, I had 4 generated not tags, once removed all
worked like a charm.

This GMF is really a damn mess.. but the very cool thing is that you can
do everything out of it!
Re: Best practice [message #186483 is a reply to message #186462] Mon, 12 May 2008 18:07 Go to previous messageGo to next message
Axel Guckelsberger is currently offline Axel GuckelsbergerFriend
Messages: 354
Registered: July 2009
Senior Member
Hi paolo,

another approach is to customize your gmf editors before they are
generated, by overriding particular XPand templates of
org.eclipse.gmf.codegen dynamically.

In addition you might evaluate the sketch models, corresponding plugins
can be found in the gmf cvs repository. Sketch models are lightweight
models close to your ecore files. I use them together with custom Figure
classes instead of graph/tool/map models. No promise that this will be
more suitable, you will have to compare it with the mainstream approach
according to your own requirements.

HTH,

Axel Guckelsberger
Re: Best practice [message #186539 is a reply to message #186483] Tue, 13 May 2008 07:54 Go to previous messageGo to next message
paolo russian is currently offline paolo russianFriend
Messages: 34
Registered: July 2009
Member
thanks I'll try for sure soon :)
Re: Best practice [message #1044108 is a reply to message #186539] Thu, 18 April 2013 13:51 Go to previous message
Nicolas Scardilla is currently offline Nicolas ScardillaFriend
Messages: 15
Registered: April 2013
Junior Member
In the end that causes this error: "can not find GenClass for class in package"???
Unable to find a clear solution for the!
Previous Topic:How to handle derived types using GMF?
Next Topic:Can't find genClass for class 'MyClass' in package myPckage
Goto Forum:
  


Current Time: Thu Mar 28 19:49:00 GMT 2024

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

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

Back to the top