The source code of Graphiti is publicly available from the Eclipse Git repository. A general page on Git at Eclipse.org can be found [http://wiki.eclipse.org/Git here]. If you just want to browse the source code without checking out all the projects, you can use this [http://git.eclipse.org/c/gmp/org.eclipse.gmp.graphiti.git/ link for the web access] to the Eclipse Git repository for Graphiti.

The source code of Graphiti is publicly available from the Eclipse Git repository. A general page on Git at Eclipse.org can be found [http://wiki.eclipse.org/Git here]. If you just want to browse the source code without checking out all the projects, you can use this [http://git.eclipse.org/c/gmp/org.eclipse.gmp.graphiti.git/ link for the web access] to the Eclipse Git repository for Graphiti.

Please set up the following Eclipse Git repository location: ''&lt;protocol&gt;://git.eclipse.org/gitroot/gmp/org.eclipse.gmp.graphiti.git'', where &lt;protocol&gt; is one of git, ssh or http dependending on what your your network infrastructure allows.

+

*ssh://userid@git.eclipse.org:29418/gmp/org.eclipse.gmp.graphiti.git

+

*https://git.eclipse.org/r/gmp/org.eclipse.gmp.graphiti.git

−

==== Committer Git Access ====

+

[http://wiki.eclipse.org/Gerrit#Logon wiki.eclipse.org/Gerrit#Logon] provides a description of how to use the Eclipse Gerrit server including how to handle IP log relevant contributions.

−

Same details as anonymous access, using git, ssh or https as protocol and specific username/password as assigned by Eclipse. Eclipse Git repository location is ''&lt;protocol&gt;://&lt;Eclipse dev user name&gt;@git.eclipse.org/gitroot/gmp/org.eclipse.gmp.graphiti.git''

+

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

+

+

*Add Graphiti to the list of your watched projects if you want to be notified about changes (mandatory for committers) here: [https://git.eclipse.org/r/#/settings/projects https://git.eclipse.org/r/#/settings/projects]

+

*Upload your SSH public keys to Gerrit if you want to use SSH here: [https://git.eclipse.org/r/#/settings/projects https://git.eclipse.org/r/#/settings/ssh-keys]

+

*Clone the Graphiti repository using one of the above mentioned Gerrit-enabled URLs

**Replace "master" with the branch you want to push to in case you want to push a change to an older release or not the master branch, e.g. b0_9_x

+

**&lt;dev_user&gt; is your development user (like mwenz)

+

**'''Note:''' The '''password can and must be generated''' here (the standard development user password does not work!): [https://git.eclipse.org/r/#/settings/projects https://git.eclipse.org/r/#/settings/http-password]

+

*When pushing to the main Git repository after the review, the IP clean flag must be set. Please ensure that all requirements regarding IP cleanliness are fulfilled!

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 http://www.eclipse.org/graphiti.

Central Build

Build Job

There are two build jobs for Graphiti on the Eclipse Hudson: the one used for the nightly dev or head build is gmp-graphiti-nightly, it is triggered by changes pushed to the Eclipse Git repository; the job emf-graphiti-maintenance is used to trigger maintenance builds for older releases (at the time of writing this it is set up to build Graphiti 0.8.x) and needs to be run manually. Graphiti uses Buckminster 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:

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

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.9.0M1

site_signing should be enabled

Use shell access to build.eclipse.org to copy 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 build job at /opt/public/jobs/gmp-graphiti-nightly/workspace) to the Eclipse download area under graphiti/updates/milestones/<build name and ID> and graphiti/archives/milestones/<build name and ID>.

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

Coding

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.

Repository

The source code of Graphiti is publicly available from the Eclipse Git repository. A general page on Git at Eclipse.org can be found here. If you just want to browse the source code without checking out all the projects, you can use this link for the web access to the Eclipse Git repository for Graphiti.

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

org.eclipse.graphiti.bot.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

org.eclipse.graphiti.tools.newprojectwizard

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

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.5, because Graphiti needs to integrate with other modeling projects that use JDK 1.5 (see Bug 361932).

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:

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.

You need to install the correct JDK; thie is JDK 1.5.

Mailing List

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