Development Environment (Committers and Contributors)
Currently GEF is built against Java 1.4. It is possible that future versions of GEF will migrate to Java 1.5 or higher versions (see Bug #204605).
Eclipse Target Platform
A given version of GEF requires the exact same version of the Eclipse Platform SDK as target. For example, GEF 3.6.0M6 is built against Eclipse Platform SDK 3.6.0M6. The GEF EDiagram example furthermore relies on a compatible EMF version.
The GEF development team uses the preceding Eclipse Platform SDK and GEF SDK release version as an API baseline to maintain API compatibility, i.e. for the 3.6 development, the API baseline is formed by Eclipse Platform SDK 3.5.2 and GEF ALL 3.5.2. Checks for API breakages and evolutions are set per project and committed alongside them.
Code Style (Formatting)
The GEF project uses the default built-in Eclipse formatter. Java-Editor Save-Actions are defined for each Java-nature plug-in of the GEF project to preserve formatting as well as organization of imports upon code changes. This was adopted in GEF 3.6.0RC2 (see Bug #308372).
Checking out the code (Committers and Contributors)
Using Team Project Set File (PSF)
- Download the Team Project Set (.psf) file and save it on your computer.
- Open Eclipse and switch to the Java perspective.
- Through the File menu, select File => Import and in the Import popup, select Team => Team Project Set and hit "Next".
- Select the Team Project Set (psf) file you saved on your disk.
- Eclipse might prompt you to create the CVS repository. Do so by either choosing a pserver connection with "anonymous" as your user name and a blank password, or extssh connection with your respective credentials in case you are a commiter.
- Each plugin of the GEF project will now be checked out in your workspace.
Committing code (Committers Only)
The GEF development team uses the following format for commit comments:
Format: [<bug-id>] <affected-branch> <contributor> <commit-date> <bug-summary>
Example:  gef-head crevells 071221 Make GEF's snapping and tools extensible to allow moving shapes with arrow keys
While the branch the code was committed to, the originator of the contribution and the commit date may possibly be redundant (since we are duplicating the information in CVS and they are already in the history), but it has been found useful to easily figure out what the actual change was. Note that in case of a third-party contribution (patch) the name of the contributor and not the committer name will be included in the comment.
Bug Handling Policy
When working with bugzillas, the following guidelines should be regarded.
When resolving bugzillas, it should be stated how the bug is verified. Preferably this is a JUnit test. Alternatively, the bugzilla will say that the defect can be reproduced in the Logic example and you can demonstrate the fix working in the logic example (or other examples using GEF). If the bug is trivial or obvious and does not require a test, we can just state this in the Bugzilla too.
Despite selecting a component, a bugzilla may be classified to more precisely specify, what part of the GEF API is concerned. We use categories for this issue, which will be stated as a [<category_name>] prefix within the bugzilla's summary. The list of currently used categories is: