Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "GEF/Contributor Guide"

< GEF
Line 18: Line 18:
  
 
===Using Team Project Set File (PSF)===
 
===Using Team Project Set File (PSF)===
* Download the [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gef/org.eclipse.gef.releng/psf/gef.psf?root=Tools_Project&view=markup Team Project Set (.psf) file] and save it on your computer.
+
* Download the [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gef/dev/gef_all.psf?root=Tools_Project&view=markup Team Project Set (.psf) file] and save it on your computer.
 
* Open Eclipse and switch to the Java perspective.
 
* 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".
 
* Through the File menu, select File => Import and in the Import popup, select Team => Team Project Set and hit "Next".

Revision as of 14:54, 24 January 2012

Development Environment (Committers and Contributors)

Java Version

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 SDK as target, i.e. GEF 3.6 is for example built against Eclipse SDK 3.6. Target definition files are provided by the org.eclipse.gef.target project, which is located in the dev cvs sub-module. The GEF EDiagram example furthermore relies on a compatible EMF version; as the example is no longer maintained, this is not included in the target definition files.

API Tooling

The GEF development team uses the preceding GEF ALL SDK release version as a baseline to maintain API compatibility, i.e. for the 3.5.2 development, the API baseline is formed by GEF ALL 3.5.1, while for the 3.6.0 development, it is 3.5.0 respectively. API-baselines are provided by the org.eclipse.gef.target project, which is located in the dev cvs submodule. 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)

All GEF source code is located in the Tools repository. Information about how to check out sources from there can be found in the CVS Howto. Most, easily you may use the Team Project Set File provided below.

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)

CVS Comments

The GEF development team uses the following format for commit comments:

Format: [<bug-id>] <affected-branch> <contributor> <commit-date> <bug-summary>

Example: [213359] 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.

Resolving Policy

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.

Categorization Policy

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:

  • General
    • [TVT] - Translation Verification Tests
  • Draw2d
    • [GraphLayout]
    • [Geometry]
    • [Text]
  • GEF
    • [Command]
    • [DnD]
    • [EditPart]
    • [EditPolicy]
    • [Palette]
    • [Print]
    • [Tool]

Back to the top