Difference between revisions of "GEF/Contributor Guide"
|Line 8:||Line 8:|
===API Tooling ===
===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 <code>org.eclipse.gef.
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 <code>org.eclipse.gef.</code> project, which is located in the <code>dev</code> cvs submodule. Checks for API breakages and evolutions are set per project and committed alongside them.
===Code Style (Formatting)===
===Code Style (Formatting)===
Revision as of 15:04, 24 January 2012
- 1 Development Environment (Committers and Contributors)
- 2 Checking out the code (Committers and Contributors)
- 3 Running a headless build locally
- 4 Committing code (Committers Only)
- 5 Bug Handling Policy
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 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.
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.baseline 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.
Running a headless build locally
Beginning with GEF 3.8.0M5, GEF has adopted a Maven/Tycho-based build infrastructure (see bug #363394 for details). With the Maven Integration installed, the headless build that is executed by a Hudson job can also be executed in the local workspace. Make sure you have checked out all projects listed within the Team Project Set provided above. Then easily run the build by right-clicking the
pom.xml file located within the
org.eclipse.gef.releng project, and selecting 'Run As -> Maven install'.
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:
- [TVT] - Translation Verification Tests