Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Reviews/Contributor Guide

Draft Content
This page is currently under construction. Community members are encouraged to maintain the page, and make sure the information is accurate.
Mylyn Reviews
Mailing ListForumsIRCmattermost
OpenHelp WantedBug Day
Browse SourceProject Set File

Development IDE Configuration

Recommended: Eclipse Helios with EGit plugins


Reviews currently have Java 1.5 and Eclipse Platform 3.5 as minimum requirements (following the Mylyn policy).

The current release always supports the last two stable Eclipse versions + the latest Eclipse milestone. Hence dependencies to newer Java and platform versions must be avoided.

Obtaining Sources


  • Download Team Project File (PSF)
  • Import -> Team Project Set and select the previously downloaded psf file.
  • Apply the Patches on the tasks (Search for task Ctrl+Shift+F12)
    • 319357 - [api] Add and hide sections from any task editor page
    • 322449 - [api] [patch] overload for TaskUiInternal.createAndOpenNewTask


Reviews sources are hosted in Git. Browse the repositories in cgit.

There are several ways to obtain a copy of each repository:

From the command line

git clone git://

From an installed EGit plugin

  • File > Import > Git > Git Repository
  • Enter URI:
  • Import projects

To compile you also need libraries from Orbit. TODO- list of libraries


Mylyn Reviews can be built using Maven 3 and Tycho.

To build the Mylyn Reviews distribution clone the Mylyn Reviews Git repository and invoke Maven on the top-level POM:

git clone git://
mvn -f package

This creates a p2 repository in






The Reviews website is located in a CVS repository on the Eclipse Foundation's servers.

  • File > Import > CVS > Projects from CVS
  • Select URL
  • Use module reviews (from www)
  • Finish

Contributing Patches

Granularity of Changes

  • Make small commits, as small as reasonable. This makes them easy to review.
  • Each commit should have a commit message that explains very clearly what the commit sets out to achieve (unless this is abundantly clear from the code itself, which is basically only the case for trivial patches). Also, when you fix a bug then report which bug you fix. When there are deeper reasons for doing things the way the commit does, then explain these as well. This all is for the reviewers and yourself: the context of the commit is completely clear.
  • Do not mix concerns in commits: have a commit do a single thing. This makes them reviewable 'in isolation'. The purpose of the commit is clear and can be understood easily by the reviewers and yourself.
  • Do not break the build and tests for any commit: this is very important for bug hunting.
  • Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.
  • A series of commits should work towards a 'feature' in a clear way and only 'enable' the feature in the last commit of the series.
  • In a series of commits first lay the groundwork and then build on that towards the feature.
  • Do not mix concerns in branches: when you encounter a bug while working on something then create a new branch to fix the bug. If your work depends on the bug being fixed then rebase your work on that new branch.

Commit message guidelines

  • The commit message header should fit on one line and should start with an uppercase letter
  • The commit message have newline characters after every 60-70 characters.
  • If there is an associated bug number in Bugzilla about it, it should come towards the end.
  • The first sentence should be a clear and concise description about the change.
  • Enter a newline before providing a more detailed description about the change.

Test before submitting

  • Run all existing tests. It does not take very long.

Sending patches by mail

Although sending patches by mail is the approved way of interacting with, and asking feedback from, the Git project, please don't send patches via git send-email. Instead, please use git format-patch to generate the mbox, and then attach that to an item in bugzilla as per the above SUBMITTING_PATCHES guides.

If you're sending a work-in-progress for a review, be aware that you can also attach work-in-progress (or RFC) items to Bugzilla; it's not just for finished patches.

Libraries from Orbit


Back to the top