It's full of classes!

"The thing's hollow---it goes on forever---and---oh my God!---it's full of stars!" (Arthur C. Clarke: 2001. A Space Odyssey)

When I presented GEF3D in the past, people often ask me if it will scale, that is if a large number of items could be displayed. Well, the following screencast, inspired by Kubrick's great movie, shows a flight through the JDK. That is, every package of the 1.000 packages contained in the JDK is visualized as a plane in 3D space. On that plane, the classes are displayed---in total, more than 20.000 classes and interfaces are shown that way. Since the whole demo is a more or less a performance test, the classes are not really layouted yet. Also, only intra-package generalizations and implementations are shown yet.



The flight is sometimes a little bit bumpy. However, flying through 20.000 elements is more or less the worse case. Usually, the camera is moved in a specific area, and only sometimes a tracking shot may be used to "fly" to the next interesting area. As you will notice at the very beginning of the video, the camera is moving quite smoothly. Well, there is still room for improvement ;-)

Note that the video does not only demonstrate the overall performance of GEF3D, but also some of its features:

• the whole flight through the package tube is a single GEF3D tracking shot
• note the high quality font rendering
• level-of-detail (LOD) techniques are implemented in two ways:
  • fonts are either rendered as texture or vector font, depending on the distance of the text to the camera
    
  • packages are painted empty, with only the name of the package, or with their content, depending on the distance to the camera. This kind of LOD technique is not part of GEF3D yet, but it can easily be added.
• actually, you see 1.000 GEF editors, combined into a single 3D multi editor

When your MWE2 workflow is not working...

MWE2 is a kind of Ant for model related tasks. Xtext is using MWE2, and I also use it to run my own Xpand generator templates. It's a nice tiny tool, and one of the nice things is that it runs in its own JVM, so you can easily extend MWE2 with new components which resides in your project. When MWE2 is started, the project settings, i.e. the classpath (including all information from the plugin dependencies), are passed to the workflow. Unfortunately, this may produce problems which are really hard to find, mostly because the error message do not really tell you where to find the actual problem. Here is a list of some problems I have run into several times (using Eclipse 3.6 and Xtext/Xpand 1.0.1). Note that all the problems mentioned and fixed below may be caused by other reasons, requiring other fixes.

Problems instantiating module

Error message:

Error message in console:

1    [main] ERROR mf.mwe2.launch.runtime.Mwe2Launcher  - Problems instantiating module ...
...
Caused by: org.eclipse.emf.mwe.core.ConfigurationException: The platformUri location '......' does not exist 

Possible fix:

Fix projectName in MWE2 file.

I run into this problem after renaming a project. Ensure the project name defined in your MWE2 file

var projectName = ".."

matches the actual project name. This line is present in Xtext related MWE2 files.

Couldn't find module with name

Error message:

Error message in console:

ERROR mf.mwe2.launch.runtime.Mwe2Launcher  - Couldn't find module with name ...

Possible fix:

Create missing src-gen folder.

I run into this problem after checking out a project from a code repository. Since we do not add generated code to the repository, the src-gen folder was not added to the repository. Hence, it was not present after having checked out the project. However, it is configured in the build.properties. This seems to lead to a problem when the classpath is computed, so that the src folder is not added to the classpath either. Since the MWE2 file resides in the src folder, is is not found and, consequently, the module is not found. I was able to fix this problem by simply creating the src-gen folder. In order to not cause this problem again, I have added the src-gen folder to the repository and ignore only its content.

Workflow definition is ignored

Error message:

None. However, the selected workflow is completely ignored. It seems as if another workflow is executed.

Possible fix:

Ensure module name of workflow, that is the first line in MWE2 file

module ..

is unique.

This seems to be a typical copy- and paste error. Actually, in deed another workflow is executed. Although one can run an MWE2 file via "Run as../MWE2 workflow", the launcher does not directly call the actual workflow file. Instead, the name of the module is read and then the internal representation of this module is been executed. If you define two of more workflows with the same module name, only one of these modules is actually present (there seems to be some kind of map from module name to module).

Couldn't resolve reference to JvmType 'Workflow'.

Error message:

Error in MWE2 workflow file:

Couldn't resolve reference to JvmType 'Workflow'.

When you try to run the workflow, the following message appears:

Please put bundle 'org.eclipse.mwe2.launch' on your project's classpath.

Possible fix:

Ensure Plug-in Dependencies are correctly added to classpath.

This error can be caused by at least one of the following problems:

• your project is not an OSGi/Plug-in project. This can be fixed by converting the (Java) project to a Plug-in project.
• as printed in the dialog, ensure 'org.eclipse.mwe2.launch' to be listed in the plug-in dependencies

While these are obvious reasons for the error, in my case I had configured the project as plug-in project and 'org.eclipse.mwe2.launch' was defined in the dependency list. However, it still didn't worked. This may be caused because I renamed the project, and probably something had gone wrong. I noticed the problem only because the Package Explorer didn't showed the entry "Plug-In Dependencies". I assume there may be some corrupt cache entries. I only was able to fix this problem by creating a new plug-in project and moving the content of the broken project into the new one.

Weird errors when generating the parser etc.

Error message:

When running the Xtext MWE2 workflow to generate the code from your grammar, weird errors occur indicating problems in your grammar.

Possible fix:

Increase memory in MWE2 runtime configuration.

I stumbled over this problem twice, and it is really annoying since it is very hard to find the reason. If the parser generator runs out of memory, it crashes at some arbitrary position and randomly creates error messages. Since it usually happens in the parser generator, the error messages always indicate problems in your grammar, although your grammar may be perfectly ok. So, if you got any grammar problems which are not that obvious real grammar problems, ensure to set VM argument "-Xmx1024m" in the MWE2 runtime configuration.

Disclaimer: This is more a personal note, and some problems may be fixed in the meantime. Feel free to tell me if I got something wrong here :-)