Skip to main content
Jump to: navigation, search


(Redirected from GMP/Graphiti)


Graphiti - a Graphical Tooling Infrastructure

This page contains useful information for developers working on the Graphiti framework itself. Users of the framework (building Graphiti-based tools) should rather have a look onto our Eclipse page at

Central Build

Build Job

Graphiti uses its own Jenkins CI instance at Eclipse. There are 2 build jobs for Graphiti on this Hudson instance:

  • The one used for the nightly dev or head build is graphiti.maven.nightly, it is triggered by changes pushed to the master branch of the Eclipse GitLab repository
  • The Gerrit voter job graphiti.maven.gerrit that runs on pushing new or updated pull request change for Graphiti

Graphiti uses Maven for its automated build and test run. See here for a detailed description of the Graphiti build process.

Providing the Build for a Milestone

These steps need to be done in order to provide a new delivery for an Eclipse milestone:

  • The week before the milestone (see below)
  • The week of the milestone(see below)
    • Do a milestone candidate build every day in the week of the milestone
    • Update News&Noteworthy document (on Graphiti site and copy into doc plugin) before building last milestone
    • Provide the final milestone build on +3 day
    • Update the downloads page on our web site with the newest ZIP file link and update site content
    • Set a Tag in the Git repository for the delivered version, the name shall be in the format <version>_<milestone>, e.g. 0.9.0_RC1
    • Do some more testing after +3 day using the EPP packages
    • Check that everything gets installed correctly from the staging update site (sent around on cross-project issues mailing list as soon as it is ready)

How to do a build for Graphiti on Hudson and provide it as a Milestone

  • Open and log on using your Eclipse Wiki user (the mail address user)
  • Go to the Graphiti build job on Hudson and select the build job (see above for the names of the Graphiti build jobs).
  • Set the build properties
    • build_type "S"
    • build_alias should be meaningfull, e.g. 0.11.0M4
    • site_signing should be enabled
  • Download the build result (ZIP and signed P2 site for 0.8 and before, ZIP and packed P2 site for versions 0.9 and beyond; both are stored after a successful build in the last_success folder of the workspace of the build job) to your local machine and then upload them to the Eclipse download area under graphiti/updates/milestones/<build name and ID> and graphiti/archives/milestones/<build name and ID> e.g. using an SFTP client.
  • Add the new update site to the composite milestones update site
    • Use SFTP to access the build server and download the JARs describing the content of the composite update site
    • Extract the XML files from them and add links to the new site
    • Update the number of children and the date
    • Create new JARs and upload them
    • There's also some ANT tasks out there that should do the job...
  • Do the testing on +2 day based on the daily milestone candidate


API Tooling

We use the Eclipse API tooling to fulfill Eclipse version number and API stability requirements. You have to define an API baseline if you are working on the Graphiti releases 0.8.x (service releases only) and beyond. For service releases use the same version as baseline (e.g. 0.8.0 for Indigo SR1) otherwise the last major release (e.g. 0.8.0 for Juno developement).

Coding Conventions

We use the standard Eclipse formatter for our coding with just one exceptional setting: the maximum line width is changed to 120. This setting can be found in the Eclipse preferences under 'Java -> Code Style -> Formatter' by editing the 'Eclipse [built-in]' profile on tab 'Line Wrapping': set the 'Maximum Line Width' in Section 'General settings' to 120.

To be sure that the formatter is really used for all your changes define your save actions (Eclipe preferences under 'Java -> Editor -> Save Actions') to include 'Format source code' with 'Format edited lines' only. Also enable the 'Organize imports' action on this page to get an automated clean-up of the import statements.


The source code of Graphiti is publicly available from the Eclipse GitLab repository at

Graphiti uses a GitLab pull requests as code review system (use your Eclipse user for login), all changes have to go through a pull request, no direct pushes to the master branch are allowed.

In short, you should do the following if you want to work on Graphiti sources and enable pushing contributions:

Here are the steps to set up EGit in Eclipse:

  1. Set environment variable HOME to define the folder where Git will clone repositories to, e.g. "C:\Users\<windows user name>\.git"
  2. Import Git repository:
    • Supported protocols for cloning are git and https
    • Recommendation is to use git (no firewall) or https (in case of a firewall)
  3. Open Windows --> Preferences --> Team --> Git --> Configuration and set the following user setting in the .gitconfig file in your HOME directory
    • <Eclipse dev user name>
    • <Email adress registered for Eclipse dev user>

The second Graphiti Git repository is for the Graphiti web site at Here's the Git url:

  • For HTTP access use ssh://<user name>

Plugin Structure

In the Git repository you will find the following projects:

examples org.eclipse.graphiti.doc Graphiti tutorial in Eclipse help
examples org.eclipse.graphiti.examples.common Common parts for samples and test tools for Graphiti; helper UIs, e.g. repository explorer and wizard(for Graphiti internal use; must not be used by the Graphiti customers)
examples org.eclipse.graphiti.examples.chess Example implementation of a Chess Game editor implemented with Graphiti
examples org.eclipse.graphiti.examples.tutorial Implementation of Graphiti tutorial in final stage
examples org.eclipse.graphiti.ui.capabilities Small example showing how the Eclipse capabilities mechanism can be used for Graphiti
features org.eclipse.graphiti.feature The feature containing purely the Graphiti framework without any additional functionality like SVG export
features org.eclipse.graphiti.feature.examples The feature containing purely the Graphiti examples and documentation
features org.eclipse.graphiti.sdk.feature The feature containing the Graphiti framework, the examples and the documentation
features The feature containing the Graphiti framework, additional framework funktionality (currently only the SVG export), the examples and the documentation
features The feature defining the Graphiti update site content, needed for release engineering
features org.eclipse.graphiti.tests-feature The feature containing the Graphiti tests
plugins org.eclipse.graphiti Graphiti framework: UI platform independent part
plugins org.eclipse.graphiti.export.batik Graphiti framework: Export functionality (e.g. save as SVG) using Batik functionality
plugins Graphiti framework: EMF pictogram model
plugins org.eclipse.graphiti.pattern Graphiti framework: an alternative generic approach to combine all implementation aspects in one pattern
plugins org.eclipse.graphiti.ui Graphiti framework: UI platform independent part
releng org.eclipse.graphiti.releng Release engineering stuff needed for the Buckminster based build
tests Graphiti internal UI and SWT Bot tests
tests org.eclipse.graphiti.tests Graphiti internal tests for UI independent part
tests org.eclipse.graphiti.testtool.ecore Graphiti internal test tool Ecore editing
tests org.eclipse.graphiti.testtool.sketch Graphiti internal test tool Sketch editing
tests org.eclipse.graphiti.ui.tests Graphiti internal tests for UI dependent part
tools A wizard that allows to create a new Graphiti-based tool plugin containing a first version of a Graphiti diagram editor for user-provided domain objects.

Working on Bugzillas (Contributions and Commiting)

This is what you should do to fully complete a Bugzilla:

  • Of course, fix the bug or provide the enhancement
  • Create a JUnit test testing the change and add it to one of the Graphiti test suites
    • Prefered tests are the pure JUnit tests, if not possible of course JUnit Plugin or SWTBot tests (as JUnit Plugin or real SWTBot test) is fina as well
    • The new test(s) should be green, of course ;-)
  • All other tests contained in all the test suites should still pass
  • Check for any warnings in your coding and fix them if possible
  • Provide some kind of raw documentation for your change, this may be directly in the Bugzilla, in the JavaDoc, on this Wiki page or in the online help (e.g. in the tutorial); this strongly depends on the character of your change.
    • Bugs will need very little documentation, while functional enhancements will need more attention on this

We follow the Eclipse rules how to use Bugzilla. Still, that leaves some points to be detailed out here:

  • New (Status NEW) bugs will (most of the time) be judged by the project lead, however if any committer has an opinion about a topic being entered as a bug he/she should feel free to take over that task. In case the bug is clearly an error or a valid enhancement request it is moved to status ASSIGNED. Otherwise the Bugzilla should be clarified by asking back. If - after an appropriate time - no answer is given, we will close the bug as being INVALID or WONTFIX or WORKSFORME or whatever seems appropriate. Also set the priority according to the pressingness of the bug.
  • We use the priority field as basic planning information: everything that is marked with priority 3 or higher (meaning lower numbers of course) is likely to get into the upcoming release. After the planning round and an established project plan, also the appropriate release flag (e.g. Indigo or Juno) will be set to +1 for things planned to go into that release, <empty> for unscheduled things and -1 for things that were planned for that release but had to be dropped.
  • Usually we do not assign a bug to anybody, instead team members decide for themselves on which bugs they want to work. The choice should of course be one from those being in the scope of the upcoming release and are highest in priority. Also the assignment for testing is done by the person wanting to test the fix, not by the one who did the change.
  • As soon as a team members starts to work on a bug, he/she should assign it to him/her, so that other team members become aware of it and double work is avoided. Until the Juno release we used only a task board in our local office in Walldorf, but this is no longer sufficient with adding additional committers not located there.
  • As soon as a bug is fixed (see above for the criteria), the bug is set to RESOLVED - FIXED.
  • As soon as the change is tested by another committer, the bug is set to VERIFIED - FIXED.
  • After the release is shipped all bugs that are part of that release will be set to CLOSED - FIXED (mostly done by the project lead, but volunteers are highly welcome!).
  • To ease the dynamic assignment of tasks to a specific milestone (one of M1 to M7 and RC1 to RC4) we use the Whiteboard field and add a string describing the milestone the fix or enhancement described here is part of, e.g. "Juno M6". There could also be several entries separated with spaces if a bug has been fixed in several releases, e.g. "Juno M4 Indigo SR2".
  • The project plan describes several Themes we would like to focus on. The Theme this bug belongs to will also be reflected in the Whiteboard field, e.g. "Theme_bugs" or "Theme_rendering"

Installation for Graphiti Framework Developers

Graphiti framework developers will need to use JDK 1.6, for releases 0.10.0 and before JDK 1.5.

As development IDE you should use the newest Eclipse installation of your choice, at the time this was written the newest Eclipse version was 3.7 (Indigo). You will need SWTBot in your developement IDE to be able to run the Graphiti SWTBot-based UI tests. Also you will need to add Buckminster (version 3.7 at the time this was written) to your installation. For more details see the Getting Started Guide.

Basically you will need the same installation for your target platform as well, but it needs to contain EMF SDK, EMF Transactions SDK and GEF SDK (see getting started guide). Buckminster is not needed here, but SWTBot is. Additionally you will need to install GMF runtime (it hosts some vector support functionality we use from export.batik plugin that you have to collect individually otherwise).

Workspace Settings

Most settings for the workspace you need to set for Graphiti framework development are maintained as project precific settings and are checked-in to our repository. So you will not need to care about things like the correct code formatters, compiler settings, API tooling settings, etc.

What you need to set additioanlly are these things:

  1. You need to define an API baseline to let the API Tooling check against. This can be done in the preferences under Plug-in Development -> API Baselines. Just add a new baseline here; the easiest way to do this is to point to an existing Eclipse installation containing the lastest major release of Graphiti. At the time of writing this (Development for Eclipse Juno), this was Graphiti 0.8.0.
  2. You need to install the correct JDK; this is JDK 1.6 for new development, JDK 1.5 for maintenance of release 0.10.0 and before.

Mailing List

The Graphiti developer mailing list allows to follow and participate in discussions on the Graphiti framework. You can subscribe here.

Back to the top