Jump to: navigation, search

Difference between revisions of "Graphical Modeling Framework/Troubleshooting"

 
Line 1: Line 1:
 
{{GMF}}
 
{{GMF}}
This "Newbie's Troubleshooting Guide" was inspired by a series of newsgroup postings contributed by Niclas Hedhman.
 
  
 
== Generation Issues ==
 
== Generation Issues ==

Latest revision as of 11:50, 4 November 2009



GMF
Website
Download
Dev Builds
Update Site releases milestones
Community
Mailing ListNewsgroupIRC
Bugzilla
Open
Help Wanted
Bug Day
Source
GMF Notation: View CVS repo

GMF Runtime: View CVS repo
GMF Tooling: View Git Repo, GitHub


Generation Issues

Missing classes following generation

  • Scenario:

You generate the "Model Code" and/or "Model Edit" from the .genmodel and you see compile errors, in the form of missing classes.

  • Probable cause:

When you right-click on the top-level element in the .genmodel editor, you will see the same actions available as in the 'package level' node. They are NOT the same. If you accidentally click on the package level one, and have not previously generated code/edit you will not get a warning and instead end up with mysterious compile errors.

  • Remedy:

Make sure you generate from the top-level node, unless you know what you are doing.

  • Suggestions:

It would be great if some form of "sanity check" be done during the generation phases, so that this type of confusion could be avoided. Alternatively, different popup menu items, which clearly makes a distinction between the two.

  • Original posting:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmf/msg01005.html

  • Comments:

This is actually an EMF usage issue, but definitely appropriate to post in the context of GMF.

Generation of packages not as expected

  • Scenario:

In EMF, by giving the top level package name a fully qualified name (e.g. org.hedhman.habba), it at first looks like the base package will be generated correctly. The .genmodel will show that the Base Package has been set up correctly.

However, after generation of the Model Code, "something" resets the package name in the .ecore model and drops everything up to the last dot, i.e. "org.hedhman.habba" is reverted to "habba" for the top level package name.

  • Probable cause:

The Model Code generator seems to be the culprit, as it indeed generates Java code for both "org.hedhman.habba" and "habba" package names in the first run, although I was under the impression that the Model Code generator wouldn't even know of the existence of the .ecore.

  • Remedy:

Don't try to mess with dots in the root level package in the .ecore model, and manually remember to add the Base Package in the .genmodel as described in the GMF tutorial.

  • Suggestions:

None.

  • Original posting:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmf/msg01033.html

  • Comments:

None.

Compiler errors following edit code generation

  • Scenario:

You generate the "edit" project and gets heaps of compile errors, all referring to the Model Code that you have just generated, and is correctly in place in the "main" project.

  • Probable cause:

You have possibly gotten the Manifest and plugin.xml of the main project out of sync. They don't seem to be updated correctly.

  • Resolution:

Delete these two files and run the Generate Model Code again. This will update those files and the referencing between the plugins will work again.

  • Suggestions:

None.

  • Original posting:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmf/msg01035.html

  • Comments:

Another EMF scenario, which is a known (advertised) "feature" ;)

Compiler errors using containment

  • Scenario:

The Model Code generation produces code that doesn't compile. You see a snippet like:

 Abc oldAbc = abc;
 abc = newAbc;

And the compile error says that "abc" is unknown and doesn't exist as a member in the current class.

  • Probable cause:

It seems that IF EClass Abc references EClass Def and vice versa, AND that both those references are marked "Containment==true" AND that the EOpposite is set to the respective fields, THEN this happens. If either, or both, Containment are set to false OR EOpposite is left blank, then the generated code will not contain this compile error.

  • Resolution:

I am at this point not sure what these two model attributes are expected to control in detail, and unable to figure out what one *should do*...

  • Suggestions:

Opposites let you specify features that effectively represent the two ends of an association. The opposite of a containment feature must be a container feature, and vice versa. The opposite of the opposite must be the feature itself.

Do not create containment references between two classes and set their eOpposite to the other, as it is not considered to be a proper construct for a model.

  • Original posting:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmf/msg01044.html

  • Comments:

Perhaps the EMF validator can be enhanced to detect this condition and present a warning to the user.

Compiler error mapping to elements not contained in the canvas element

  • Scenario:

You get a compile error in the Editor code, where the code tries to do;

 abc.getXyz();

where is of your top level model class, but does not have a "xyz" reference. However, you have a "def" reference in EClass Abc that points to a EClass Def that in turns have a "xyz" reference to something.

  • Probable cause:

You have created a Node Mapping between the EClass Xyz and the "xyz" reference in EClass Def.

  • Resolution:

I don't know if this is expected behavior or not, but it seems that you need to put a reference (0..*) in the the top level model EClass for all EClasses that are mapped to canvas level elements.

  • Suggestions:

This used to be the behavior of the generator, but has been corrected per this bug.

  • Original posting:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmf/msg01046.html

  • Comments:

None.

Compiler errors in generated editor

  • Scenario:

You generate the "editor" from the .gmfgen model and gets compile errors like:

for (Iterator it = abcElement.getXYZs().iterator(); it.hasNext();)

saying that there is no getXYZs() method, even though it is in your .ecore model.

  • Probable cause:

You have modified the .ecore and forgotten to re-generate the Model Code and Edit Code, from the .genmodel.

  • Resolution:

Just "Reload..." the .genmodel and run the "Generate Model Code" and "Generate Edit Code" commands.

  • Suggestions:

None.

  • Original posting:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmf/msg01049.html

  • Comments:

Another EMF item that is applicable to GMF in that a "Reload..." option would be helpful for its generator model.

Nodes not able to be created on canvas

  • Scenario:

The generated code doesn't allow one or more tools to create elements on the canvas. You only get a cross.

  • Probable cause:

The Containment attribute for the EReference from the EClass that is mapped to the canvas to the object that you are trying to add (via its mapping), is not set to true.

  • Resolution:

Go to the .ecore and locate the Containment attribute in the EReference to the object type that the tool is mapped to, and make sure it is true.

  • Suggestions:

None.

  • Original posting:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmf/msg01050.html

  • Comments:

Improved validation rules should catch this in the future.

Compiler errors when selecting wrong package

  • Scenario:

You generate the Editor code from the .gmfgen model, and you get compile errors;

import org.hedhman.niclas.AbcPackage;

saying that the AbcPackage is not found. And that is correct, the "Generate Model Code" have not created something like that.

  • Probable cause:

You have mistakenly selected the wrong package in the Canvas Mapping in the .gmfmap Mapping.

  • Resolution:

Go to your .gmfmap model, find the "Domain Model" attribute in "Mapping" -> "Canvas Mapping" and change the package to the correct top level package, e.g. "EPackage org.hedhman.niclas.abc.habba"

  • Suggestions:

None.

  • Original posting:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmf/msg01104.html

  • Comments:

None.

Generator Model

Message: containmentMetaFeature must be set

Scenario, You are editing along your models and during the "Create Generator Model..." of the .gmfmap, you get a cryptic message like;

  The required feature 'containmentMetaFeature' of
'org.eclipse.gmf.codegen.gmfgen.impl.TypeModelFacetImpl@1ea76be{platform:/resource/org.ops4j.drydock/model/drydock.gmfgen#//@topLevelNodes.4/@modelFacet}'
must be set

  The required feature 'childMetaFeature' of
'org.eclipse.gmf.codegen.gmfgen.impl.TypeModelFacetImpl@1ea76be{platform:/resource/org.ops4j.drydock/model/drydock.gmfgen#//@topLevelNodes.4/@modelFacet}'
must be set
  • Possible cause:

The so called "Containment Feature" property in the NodeMapping of an Element is not set, perhaps because the property Containment in the .ecore model of the Element in question was set to false.

  • Resolution:

The error message mentions topLevelNodes followed by a dot and a number. Go to the just generated .gmfgen model and in the .gmfgen resource, you will find a set of "Gen Top Level Node" under the "Gen Diagram Xyz" root node. Starting at 0, count to the Nth node indicated in the error message, that gives enough information which mapping node has problem. Got to the .gmfmap model, and locate the "Containment Feature" property for the Node Mapping corresponding to the element just located in the .gmfgen model. It is likely to be the Nth NodeMapping element in the .gmgmap model as well. Make sure the "Containment Feature" has a valid value.

  • Suggestions:

None.

  • Original posting:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmf/msg01151.html

  • Comments:

None.

Runtime Issues