Plug-ins as model containers

Creating plug-in projects to contain models is easy with PDE: not even a single line of code is needed. The user can create a non-java plug-in project, or convert a resource project to plug-in project by clicking on ‘Configure/Convert to Plug-in projects’ in the pop-up menu of the project.

It’s finished: the user now can define dependencies between projects and even install/update third party plug-ins from update sites!

Creating cross-links

Of course, if the user wants to use the models from the dependent plug-ins we must show the contents of these models on the GUI. This step is highly domain-specific, therefore I leave it to the reader. The part of determining the visible resources from the imported plug-ins is common for all uses.

To use the dependent models, we need to load not only the directly referenced plug-ins, but the plug-ins needed by them recursively:

/**
 * Collect all plug-ins on which the given plug-in depends.
 * @param name
 * @return
 */
public static List<String> collectAllDependencies(String name){
    Set<String> all = new HashSet<String>();

    Queue>IPlugin< process = new LinkedList<IPlugin>();
    process.add(getPlugin(name));

    while(!process.isEmpty()){
        IPlugin plugin = process.poll();
        all.add(plugin.getId());
        for(IPluginImport pi : plugin.getImports()){
            String imported = pi.getId();
            if (!all.contains(imported)){
                process.add(getPlugin(imported));
            }
        }
    }

    return new ArrayList<String>(all);
}

public static IPlugin getPlugin(String name){
    IPluginModelBase mb = PluginRegistry.findModel(name);
    IPluginModel m = (IPluginModel)mb;
    return m.getPlugin();
}

When we got all plug-ins to use, we just need to collect the resources from them. In this step we must prepare for two cases: whether the plug-in is a workspace plug-in or not. A workspace plug-in is a plug-in in development. There is a project in the workspace which contain the plug-in contents. Unlike installed plug-ins which exists in the plugins directory of the eclipse installation:

public static Collection<URI> getVisibleResources(String pluginname) throws CoreException{
    IPlugin plugin = getPlugin(pluginname);
    final Collection<URI> result = new ArrayList<URI>();

    //The plugin has an underlying resource if it is a workspace plug-in
    IResource r = plugin.getPluginModel().getUnderlyingResource();
    if (r != null){
        r = r.getProject();
        r.accept(new IResourceVisitor() {

            @Override
            public boolean visit(IResource resource) throws CoreException {
                if (resource instanceof IFile){
                    result.add(URI.createPlatformResourceURI(resource.getFullPath().toString(), true));
                    return false;
                }
                return true;
            }
        });
    }else{
        Bundle b = Platform.getBundle(plugin.getId());
        Enumeration<URL> urls = b.findEntries("/", "*.e", true);
        while(urls.hasMoreElements()){
            URL url = urls.nextElement();
            URI uri = URI.createPlatformPluginURI(pluginname+url.getPath(), true);
            result.add(uri);
        }
    }

    return result;

}

As for normal eclipse plug-ins, if a workspace plug-in exists with the same name as an installed plug-in, the workspace version will be used.

Because EMF needs all resources to be loaded into one resource set to resolve crosslinks, it is advised to use some kind of indexer to reduce load times.

Special case: Xtext

If you’re using this method with Xtext, some things will become much simpler as it provides you some additional infrastructure compared to EMF. First, you won’t need to write your own indexing service as Xtext does everything for you from caching to lazy linking. Second, you can implement your own builders as builder participants, which leverages the problem of creating and configuring resource sets and loading resources.

The easiest way to use PDE functionality is to implement the possible crosslinks as scopes:

public class PluginDependencyScope extends AbstractScope {

    private final List<IEObjectDescription> descs = new ArrayList<IEObjectDescription>();

    /**
     * @param parent
     * @param ignoreCase
     */
    public PluginDependencyScope(URI context,ResourceSet resourceset, IScope parent) {
        super(parent, false);
        String projname = context.trimFragment().segment(1);
        List<String> deps = MODembedCore.collectAllDependencies(projname);

        for(String d : deps){
            try {
                for(URI uri : MODembedCore.getVisibleResources(d)){
                    try{
                        Resource r = resourceset.getResource(uri, true);
                        for(EObject eo : r.getContents()){
                            if (eo instanceof Package){
                                String name = ((Package) eo).getName();
                                QualifiedName qname = QualifiedName.create(name.split("\\."));
                                descs.add(EObjectDescription.create(qname, eo));
                            }
                        }
                    }catch(Exception e){

                    }
                }
            } catch (CoreException e) {

            }
        }
    }

    /* (non-Javadoc)
     * @see org.eclipse.xtext.scoping.impl.AbstractScope#getAllLocalElements()
     */
    @Override
    protected Iterable<IEObjectDescription> getAllLocalElements() {
        return descs;
    }

}

Problems

This does the magic, but it’s not perfect. There are some major flaws which are not easy to deal with:

• Depending on PDE pulls the entire PDE+JDT into your product even if your user does not intend to use it. This is a minor problem, it just causes overhead on the disk usage.
• PDE is defined mainly for Java Plug-in projects. The whole user interface contains items which are meaningless in our special case.
• If the user is not familiar with PDE and OSGi concepts, she/he will have a hard time understanding the user interface and the operation of cross-link resolution.
• When the user tries to add a plug-in to the dependency list, all installed plug-ins are listed, including platform, PDE, JDT, EMF and other components. It may be hard to tell which plug-in contain models of a specific domain.

Conclusion

Functionally, PDE contains everything you will need for partitioning models. If the targeted user base is experienced with eclipse, reusing PDE is an option. If needed, some isses can be worked out with some effort. For example the MANIFEST.MF editor can be replaced with a more domain-specific editor, which can filter out uninteresting plug-ins from the dependency list and include additional information which may needed by your domain.

I’m using this technique to share some common libraries to users for my own domain-specific language. It’s better than telling the user to download some files and copy them to the workspace. Let me know if you found better ways.

This year, a collegue of mine, István Ráth will attend at EclipseCon Europe, and during the Modeling Symposium present the basic use cases of the tool. In the following I attach a short abstract of the talk to give a basic idea:

EMF-IncQuery: Incremental evaluation of model queries over large EMF model

A Talk at the EclipseCon Europe 2011 Modeling Symposium
Presenter: István Ráth

High-performance model queries are still a major challenge for the industry standard Eclipse Modeling Framework (EMF), as they are intensively used in various model validation, model transformation or code generation scenarios.

Existing EMF-based query technologies (like OCL, EMF Query or native Java programs) have significant scalability issues for models over 50000 model elements. Moreover, it is often tedious and time consuming to efficiently implement EMF-based queries manually on a case-by-case basis.

This talk introduces EMF-IncQuery, a declarative and scalable EMF model query framework. EMF-IncQuery uses a graph query language, and provides incremental query evaluation by caching the results of the model queries and incrementally maintaining the cache when the underlying EMF model changes. Furthermore, the EMF-IncQuery framework can be easily integrated into existing EMF-based applications in a non-intrusive way.

During the talk, we quickly overview how easy it is to define and integrate highly scalable model queries into existing EMF-based applications, in the form of a very short live demonstration using the MDT Papyrus modeling tool. The scalability of the engine will also be demonstrated, with on-the-fly constraint revalidation that takes less than 100 milliseconds over large AUTOSAR models with over 1 million elements.

 

More info: http://viatra.inf.mit.bme.hu/incquery

Unfortunately, I cannot go to the conference, but I hope, the 10th birthday of Eclipse will be celebrated well. Have fun, and if you are interested, listen at our talk.

SourceCloud of the Debug Visualisation Project

However, it is interesting, that the strings ‘end_of_line‘ and ‘sp_cleanup‘ found their way in. Luckily, only a few one-character names and numbers are present, meaning, we managed to created longer variable names…

The cloud of the VIATRA2 model transformation framework is more interesting: it is a much larger codebase, developed for several year by around a dozen people. Because of the size I generated the cloud using 300 words, but almost no Java keywords found their way into the graph.

SourceCloud of the VIATRA2 framework

However, the mandatory comment parts did, e.g. nbsp or the names of some creators. A lot of EMF-specific keywords are also present. They are present because we have quite a large EMF metamodel that provides several hundred generated Java files.

At last, but not least I also checked the cloud of the EMF-IncQuery project. This is smaller, then the VIATRA2 project, but larger then the Debug Visualisation. Additionally, it has a shorter history, but with several key committers.

SourceCloud of the EMF-IncQuery project

My personal favorite is this diagram, as it shows a lot of nice things: e.g. four digit numbers in large quantities (magic numbers FTW) or the absolute champion string: ‘HUKfyM7ahfg‘. All of them are present in the Ecore Diagram of the defined metamodel (the meaningless string 152 times as a postfix of an identifier ). At least, I learned something about the internal model representation of GMF.

And how do your projects look like?

EMF-IncQuery provides an incrementally evaluated model query framework: as the underlying EMF model is changed, the query results are re-evaluated, and are instantly returned when needed. Queries are formulated using the pattern language of the VIATRA2 transformation system, and the Java code necessary to execute queries are generated.

In our demo application we extended the Papyrus UML editor with on-the-fly validation of well-formedness constraints. During editing we check for non-local constraints (e.g. a Behaviour must have the same number of parameters as the corresponding operation); display the results in the editor and in the problems view; we try to provide and remove these error markers without saving or manual need to start validation.

Basically, the constraint validators are generated from specially annotated VIATRA2 patterns; the generation is currently somewhat specific to the Papyrus editor, but can be extended to support most EMF-based editors easily.

A screencast of the demo is presented below. It is important to note, that the Papyrus editor was not modified in any way, and the framework generated all Java code used during validation. More details about the demo application, such as source code, tutorial slides, can be found on the homepage of the application.

(If the embedded video does not show – e.g. in a feed reader – you could watch it on on Youtube)

I have discovered a truly remarkable proof of this theorem which this margin is too small to contain.
Pierre de Fermat

During the development of editors it is often needed to display additional information next to the document, such as error markers, search results or various coverage metrics. However, it is not a good idea to hardcode the list of supported markers during development, as the best ideas will be introduced by others – who do not want to have anything to do with our editor.

Luckily, Eclipse provides a simple way to attach markers to documents without explicit support needed from the editor developer: the markers (and annotations) created by their corresponding extensions are stored independently from the document, so these additions can be made without disturbing any existing user of the files.

As I described it in my previous post about error markers, such markers can be defined creating an extension for the extension point org.eclipse.core.resources.marker, and then using the IResource.createMarker() method to create the marker instances as needed. Then using some magic it can be displayed as the yellow or red wriggly lines during the text.

Other markers (and annotations) can be created in similarly: we create our own marker type, and register an annotation type for it, and the platform manages the rest. In my case I wanted to represent a calculated set of program statements similar to the code coverage display used by the EclEmma tool: the covered statements are highlighted with the green background.

To support such a display, I created a new marker type, that is a text marker; and to make the lifecycle-management easier, I did not set it persistent. This has been reached using the following code:

<extension
    id="org.eclipse.viatra2.slicemarker"
    name="GTASM Slice"
    point="org.eclipse.core.resources.markers">
  <super
    type="org.eclipse.core.resources.textmarker">
  </super>
</extension>

The most important difference between this marker and the one defined in the previous Markers and Annotations post is that the newly defined marker is not a problem marker, but a simple text marker. This means, the created marker will not show in the Problems view (that is nice – we don’t want to display problems now), and no default annotation is created (that will need fixing).

In theory it is possible to create annotations programmatically together with the markers, but in practice it is really a bad idea. First of all, annotations are created for the document model (thus assuming an open editor and a code dependency to that document model), are never persisted, and the resulting code fails indeterministically (I once debugged a code like that, every annotation creation code ran correctly, but some annotations were missing; re-running the code re-added the missing ones, but sometimes removed others), so this idea will not work.

Luckily, the platform provides two extension points that can be used to automatically assign annotations to marker instances. To define an automatically generated annotation type for the markers, the org.eclipse.ui.editors.annotationTypes extension point is used: basically a marker and an annotation ID is stored this way.

   <extension
         point="org.eclipse.ui.editors.annotationTypes">
      <type
            markerType="org.eclipse.viatra2.slicemarker"
            name="org.eclipse.viatra2.slicemarker">
      </type>
   </extension>

To define the appearance of the created annotation the org.eclipse.ui.editors.markerAnnotationSpecification extension point can be used. In the extensions we have to specify the annotation display methods used together with color and formatting settings.

   <extension
         point="org.eclipse.ui.editors.markerAnnotationSpecification">
      <specification
            annotationType="org.eclipse.viatra2.slicemarker"
            colorPreferenceKey="org.eclipse.viatra2.slice.color"
            colorPreferenceValue="192,255,192"
            contributesToHeader="false"
            highlightPreferenceKey="org.eclipse.viatra2.slice.highlight"
            highlightPreferenceValue="true"
            includeOnPreferencePage="true"
            label="GTASM Slice Marker"
            overviewRulerPreferenceKey="org.eclipse.viatra2.slice.overview"
            overviewRulerPreferenceValue="true"
            presentationLayer="0"
            textPreferenceKey="org.eclipse.viatra2.slice.text"
            textPreferenceValue="true"
            textStylePreferenceValue="BOX"
            verticalRulerPreferenceKey="org.eclipse.viatra2.slice.ruler"
            verticalRulerPreferenceValue="true">
      </specification>
   </extension>

Even better, by assigning preference keys to the various settings the platform also offers the users the possibility to configure the annotations: the General/Editors/Text Editors/Annotations preference page will list our annotation, and allows setting its preference values. If the preference keys are unique (that is our responsibility ), then creating this extension ends our work: annotations will be generated automatically, and they will be displayed in the opened text editors.

Annotation Preferences

The marker creation process is entirely the same as the creation of error markers: a new marker is initialized using the IResource.createMarker(String markerId) method, and the IMarker.CHAR_START and IMarker.CHAR_END markers are set for positioning the markers.

An editor opened with the annotated code

Alltogether, the markers and annotations provide an easy way to extend existing editors with meta-information (e.g. execution state, dependencies, coverage, etc.), that can be used with a very little amount of Java programming. Sadly, the content assists for extensions is not that discoverable as the Java APIs, so a lot of experimenting and/or documentation reading is needed. Luckily, documentation is available for these extension points, so knowing their name will be enough for most cases.

So, lets hope, Eclipse gives us a big enough margin to contain our proo metainformation.

However, we had a different need together with the VIATRA2 project: we explicitly forbid in our internal policy modifications to the generated Java code in order to avoid non-reusable models, and as this way the generated code does not contain any extra information to the generator model, we do not want to store the Java classes in our Subversion repository.

Another minor obstacle was that the code generation does not happen automatically (e.g. as in the LPG editor of the IMP project) – so simply not committing the generated code to the repository would mean a manual invocation of the generator that is inconvenient.

Luckily, the code generator is available using specific ANT tasks, allowing to write a build file that describes how to generate the required Java code, reusing the existing build model if necessary:

<emf.Ecore2Java
 genModel="org.eclipse.viatra2.gtasm.model/model/gtasmmodel_updated.genmodel"
 model="org.eclipse.viatra2.gtasm.model/model/gtasmmodel.ecore"
 generatemodelproject="true"
 generateeditorproject="true"
 generateeditproject="true"
 reconcilegenmodel="reload" >

Some interesting points:

• As the selected Ant task is provided by an OSGi plug-in, it is important to set the Runtime JRE to the same one as used by the workspace, otherwise the called task will not be found.
• As the genmodel generator is not available as an Ant task, the ecore2Java task was used. In this case it is important to use the [cci]reconcilegenmodel[/cci] attribute to avoid the unnecessary override of the genmodel
• Regardless of the value of the [cci]generate*project[/cci] attributes if the [cci]*project[/cci] were not given as sub-tags, the corresponding code was not generated. This seems like a bug for me, as this duplicates information already present in the genmodel, but I am not sure.
• The code generator does not set the generated files Derived attribute, thus it is not excluded from the svn repository. Unfortunately, it is not possible without writing custom tasks, as there is no such command (yet) in Eclipse (but hopefully the patch gets committed in Indigo).

This ant task mimics the GUI-based code generators functionality, thus fulfilling our needs, except two things: it does not exclude generated code from the repository, and does not run automatically.

The repository exclusion is resolved using a hack: the [cci]src[/cci] folders are listed in all generated projects in the svn:ignore variable – thus manually disallowing their sharing. This approach works well, because if no code is generated, the [cci]src[/cci] folder might be missing, that is marked with a very explicit error message (as it is still referenced in the project properties), but if the task is executed, the folder is created as well (and the source folder reference will be working).

For the automatic building Eclipse provides a neat way: External tools (e.g. Ant scripts, or shell scripts, etc.) can be added as project builders. A Run configuration has to be created for the selected task, that can be added to the project. This means, our script is executed each time the selected project changes

Builders page in the Project properties

Finally, some other modifications were made to the task in order to provide a more standard build: first, as not the entire project is generated at every invocation of the script (the projects could not be deleted, because the generator does not support setting the version number of the generated edit and editor projects), if all project stubs are downloaded from the repository, the build order might not be adequate. To overcome this, a manual build is executed for all projects at the end.

A second modification is a clean task, that removes all source folders, in order to provide a “clean”, out-of-the-box experience for a regeneration. This task can also be registered at the builder properties.

The full, modified script looks as following (using Gist from Github):

Update: the eclipse.build tasks are not available in Eclipse, as mentioned by a comment. They are provided by the Buckminster tool, and are not required for the EMF code generation, so it is safe to remove them. However, in this case the refreshing and building of the projects have to be managed in another way (e.g. registering the Ant script as an External builder for the projects).

This simple script helps in a lot of cases – and because the ecore models does not change very often, its performance is not really an issue (we have quite a large ecore model, so the generator runs about 30-40 seconds). My main issues are the following:

• I don’t like to reproduce information from the genmodel in the build script. I am not entirely sure which information is read from the genmodel and which is inferred from the parameters, making the solution a bit volatile.
• The missing derived flag command. It would be quite a nice touch if the code would take care of it.

Alltogether, if you like it, feel free to use it (licensed under EPL). I also would be glad if somebody could give me a hint about how to enhance the script – this is only my second Ant build script, so I don’t know the language very well.

Ninety per cent of most magic merely consists of knowing one extra fact.
Terry Pratchett, Night Watch

Development in Eclipse keeps fascinating me, as there are a lot of very thoroughly designed services and features integrated to allow detailed customization – on the other hand, “with big power comes big responsibility”, but at least a steep learning curve. I had such an experience with the problem handling support not long ago.

We developed our own textual language, that provided error markers and editor annotations as error feedback. The problem was that the editor annotations were sometimes missing: our planned functionality worked like we like to add an annotation each time our marker was added, but the annotations were not always updated (so we got an inconsistent state between markers and annotations – but not every time).

Of course that was caused by the fact that we were rolling out our own implementation of marker/annotation synchronization – we were not aware that the JFace TextEditor provides such a service out of the box – and I did not found it documented on the various locations (that’s why this blog post is born ).

Our requirements

First of all, lets assemble the various ways Eclipse editors can provide error feedback:

• The most basic (and least usable) way is the use of pop-up windows – they are annoying, and not persistent (after pressing a button, they disappear, before the error could be solved).
• Writing to the Error log view – a bit better, but the log could be overwhelmed, if the messages are too many, because they cannot be deleted when the problem is solved.
• Displaying the error in the Problems view – that’s one of the standard places, where parse errors should be displayed. The problems view is generated by reading (and filtering) the error marker type (org.eclipse.core.resources.problemmarker).
• Marking the files in the Project Navigator view with a small symbol, if they contain errors/warnings. This is also handled using the previously mentioned error marker.
• Underlining the erroneous parts in the editor. For this reason annotations should be added to the JFace Document Model used by the JFace TextEditor component.

The basic idea is to create a marker and an annotation each time a problem is found. The problem with annotations, that creating them requires some connection with the editor object, or at least the document model, but our parser should not depend on the editor (core component should not depend on the GUI!).

Mark My Words!

The management of the markers is well described in the Mark My Words tutorial. Basically markers are attached to IResources, and provide a simple key-value interface with a freely definable key set (and the IMarker interface specifies some commonly used keys).

Following the tutorial we could create our own marker with the parent of the org.eclipse.core.resources.marker marker, after this adding the markers to the selected files managed the error display in the Problems and Project Navigator views.

So our marker definition looks as follows:

   <extension
         id="org.eclipse.viatra2.loaders.vtclparsermarker"
         name="VTCL Parsing Problems"
         point="org.eclipse.core.resources.markers">
      <super
            type="org.eclipse.core.resources.problemmarker">
      </super>
      <persistent
            value="true">
      </persistent>
   </extension>

The problem marker understands severity, error message and line number parameters, and is capable of displaying them in the Problems view.

IMarker marker = file.createMarker(markerId);
 marker.setAttribute(IMarker.SEVERITY, severity);
 marker.setAttribute(IMarker.MESSAGE, message);
 marker.setAttribute(IMarker.LINE_NUMBER, line);

Annotating the document manually

As stated before, markers could be added easily without knowing anything about who has opened the file currently, so they are really useful for error feedback, but this information should be also available in the open editors.

Our first idea may be to create some glue code, that listens to the marker changes, and updates our editor accordingly. The drawbacks of this approach are first the fact that we have to code something that trivial, and the second (as we saw in our project), that the editor update could be quite tricky (missing or not deleted annotations).

My theory is, that we have encountered some kind of race condition with our naive implementation, as the annotation creation code was always executed, but sometimes the results were lost. So, in the end, this listener is not so trivial.

Automatic annotation display

This was the part that gave us the most headache – we did not understand, what caused the inconsistent display problem. On the other hand, knowing one extra fact (“magic”) the problem is trivially solvable.

So, here comes the Eclipse magic: we don’t have to create this service manually, we should reuse the already existing one. For that, we would need that our marker also become a child marker of the org.eclipse.core.resources.textmarker, and a minimal set of position data should be added to the marker.

This position information is described by the start and end offset value – instead of the human-readable line/column position information a machine-readable single position is used: the number of characters that has to be read from the start of the string stream. Its lucky, that most parser generators provide such output that this information is trivially available from the AST level

   <extension
         id="org.eclipse.viatra2.loaders.vtclparsermarker"
         name="VTCL Parsing Problems"
         point="org.eclipse.core.resources.markers">
      <super
            type="org.eclipse.core.resources.problemmarker">
      </super>
      <persistent
            value="true">
      </persistent>
      <super
            type="org.eclipse.core.resources.textmarker">
      </super>
   </extension>

And the marker creator Java code looks as follows:

IMarker marker = file.createMarker(markerId);
marker.setAttribute(IMarker.SEVERITY, severity);
marker.setAttribute(IMarker.MESSAGE, message);
marker.setAttribute(IMarker.LINE_NUMBER, line);
if (pos.offset != 0) {
  marker.setAttribute(IMarker.CHAR_START,pos.offset);
  marker.setAttribute(IMarker.CHAR_END,pos.offset+pos.length);
}

After that, the platform uses a default implementation, that provides the well-known wriggly underline to annotate our text files with the associated markers.

Summary

Alltogether, the following steps are needed to provide a simple error reporting for our existing editor:

• Create a custom marker type
  • With a supertype of org.eclipse.core.resources.problemmarker to display the report in the problems view
  • With a supertype of org.eclipse.core.resources.textmarker to underline the errors in the textual editor
• Create a marker instance
  • Setting the IMarker.SEVERITY, IMarker.MESSAGE and IMarker.LINE_NUMBER attributes for the Problems view.
  • Setting the IMarker.CHAR_START and IMarker.CHAR_END for the editor annotations.

Conclusion

The Eclipse text editors provide a well-defined, easy to use error reporting mechanism nearly for free. The main catch is, we have to be careful to set everything – if something is missing, we got the silent failure issue – no exception is thrown, but something is not shown.

The biggest issue in our implementation was that the IMarker.CHAR_START and IMarker.CHAR_END marker attributes are ignored, if the used marker is not a text attribute, making this problem hard to identify.

A fine thing with this error reporting mechanism is, that it is independent of the concrete text editor used: when we changed our implementation in the VIATRA framework, the resulting reports were visible in every text editor (e.g. the dedicated VIATRA text editor, or the default text editor in Eclipse) – thus helping error recovery.

The possible solutions are either ignoring this fact, using a special environment, where all the appropriate settings have been made, or tweaking the development environment. The tweaking will not work, as several settings should be made, and they are easy to forget, while the special presentation environment seems too much of a hassle for me. This left as the only choice to ignore the fact.

But finally I had some hacking time, so I created a Presentation theme for Eclipse, that solves tweaking by a single selection of the user interface: Themes can be selected in the General/Appearance tab on the Preferences page.

Currently, the theme description is a bit hacky: for every platform the default font is copied by hand to the plugin.xml (using a Windows 7, a OpenSuse 11.3 Linux and a Snow Leopard machine). More research is needed to solve this in a more generic way. Luckily only four fonts have been redefined by the theme.

Some things missing: support for resizing elements in JFace viewers (such as EMF tree editors or CNF views), and the theme was not tested with graphical editors – although they can be resized using the Zoom control.

Finally, an early alpha version can be downloaded from our update site: http://eclipse.cubussapiens.hu

I’m looking for some feedback, or either alternative implementation ideas; I think, others have already met these problems.

The source is available from GitHub.

Update: before/after screenshots below.

Before: The default theme

After: Presentation theme

The error messages were a little bit cryptic (but all similar in nature): A containment reference of a type with a container feature platform:/resource/org.eclipse.viatra2.gtasm.model/model/gtasmmodel.ecore#//gtasm/metamodel/gt/GTPattern/namespace that requires instances to be contained elsewhere cannot be populated.

This was scary, as I don’t remember any new core features in EMF 2.6, that suggest such changes. My second guess was a misedited model, but after checking, that I have the same models as half year ago, this proved wrong. Even worse, these errors did not appear in either the Problems or Error log view. Checking the items mentioned in the error messages did not help, as the model elements looked “innocent enough” not to question their content.

It was only know when I saw that these errors are shown in a new, problem page in the editor (I often miss the editor pages option – except on form-based editors), and on the other page the tree is displayed, and code generation seemed also working.

At this point I looked on the internet for similar problems, and found a thread about the issue in the EMF newsgroup. The main idea was Ed Merks’s comment:

The point is supposed to be that you can’t be contained by more than one container, so you can’t have a container references that’s required as well as any other containment reference that’s not the opposite of that required container. I.e., a required container prevents other containment references from ever being populated.

Using this information I finally understood, what the error message meant, and begin looking for the cause in the Ecore model. After some searching (the error message only mentioned one model element from the three actors, and it is hard to get an overview of the inter modelelement relations in an EMF tree editor), I finally found the mentioned elements, that looked quite innocent at first – just take a look at the included graphical representation.

Illustration of the found problem

We have a machine, that contains both patterns and rules, while rules may contain addition pattern definitions (named local pattern definitions). On the other hand, patterns and rules have a backreference to the  machine (namespace). As we wanted to have the Machine reference available for local patterns, the pattern references exactly one machine.

The drawback of the solution is, that the machine reference is the inverse of the containment relation, so every pattern has to be contained in a machine. On the other hand, EMF requires that every EObject (not EClass) must have exactly one incoming containment reference for serialization, so it is not possible for a rule to be the container of a pattern – hence the error message.

This analysis is extremely useful: it shows, that our metamodel prevents having serializable models in some cases, which comes in handy (I wouldn’t like to be the one, who has to debug such an error after a runtime exception is caught…). The fix is not really straightforward, as this model is already used (interesting fact, that the issue has not been produced in runtime – this means, we don’t have 100% test coverage ), but by having a map to the error it is easier to fix.

I’d like to thank for the EMF team for this fine analysis solution, but some minor additions: don’t add warnings to a new page, use the existing reporting options; and try to rephrase the message for it to become more understandable.

In my experience since P2 came as a provisining platform the Update site projects were not the best available solutions: at first (in Ganymede) they did not produce everything P2 needed, while produced legacy information, that triggered a backward compatible mode in the provisining platform (officially the old Update managers site.xml should not be used). Even worse, I experienced some serious errors, when trying to add a new version of the already added plug-ins to the already built update site – in most cases the category definitions were removed (as in Galileo by default all features without category are hidden, this problem is quite serious).

On the other hand, not too long ago classic update sites were also needed to provide update sites for both the Update manager and P2. Today the Update Manager compatibility is not as crucial, as all Eclipse versions supported by eclipse.org use P2, so it is better to use some dedicated P2-based mechanism for Update site creation.

This mechanism is present since Eclipse 3.4 (at least from the command line, as documented in the Eclipse wiki), but is a bit hard to use. Recently I found a somewhat hidden option in the GUI, that provides the P2 metadata generation functionality – just as needed.

To use this, at least one (or possibly more) features are needed – the features are the minimum installable units. When the features are ready and the related plug-ins are attached, the Export wizard has to be invoked with the Deployable Features wizard from the Plug-in Development category.

The deployable features and the destination should be selected as needed (in my experience the directory export makes possible the easiest update site deployment, while the zipped archive allows the easiest direct transport – e.g. for dropins).

Export deployable features wizard

The P2-related magic should be initiated on the Options page: if the Generate metadata repository option is selected, as in the screenshot, during the export all metadata needed by P2 is generated.

For categorization of the repository a specific xml-file should be created: by creating a Category Definition from the New… wizard a simple form-based editor can be used to define categories for the installer, that can also be selected using the Export wizard.

Some additional tips and tricks related to the deployment:

• To update existing P2-based update sites, simply point the export destination to the already existing update site. This updates the existing update site – I only tried this using the directory-based output.
• To avoid runtime issues, make sure that the exported plug-in projects use the needed Java version compatibility in the project settings (e.g. if the manifest requires Java 1.5, make sure the project gets compiled in Java 1.5 compatibility mode), as the plug-ins are recompiled using these settings. I managed to get a Java 1.5 compatible project compiled with Java 1.6 compliance settings – the plug-ins even got installed, but did not work in the target computer, instead a hard to debug runtime exception is thrown.
• It is possible to add source boundles by selecting the appropriate checkbox. On the other hand I couldn’t find a way to set the display name of the generated source bundles, and they are shown with the same name as the non-source plug-in, making it hard to distinguish between them during runtime. If you know the solution, please let me know.

In general, this export mechanism works well, without any major issues, I tested in repeatedly with several update sites. Unless for some reason Update manager compatibility is needed, I don’t recommend using Update site projects anymore – simply export your features to deploy.