Home Tutorials Training Consulting Products Books Company Donate Contact us

NOW Hiring

Quick links


This tutorial explains how to contribute to the Eclipse open source project for the Eclipse IDE.

1. Contributing to the Eclipse open source project

1.1. Code contributing

Eclipse projects are an open source projects. Multiple developers - companies and individuals alike - advance the code. Everyone has read access to the code repositories hosted at eclipse.org. It is possible for you to get the source code, modify it and provide the change back to the project. Most Eclipse projects use a code review process based on the Gerrit code review system, some use Github.

Contributing to an Eclipse project has the benefit of getting feedback directly from the core developers. It also allows developers and organizations to fix bugs which affect them and to drive the project into a desired direction.

This script focuses on the process of contributing code to an Eclipse project. If case you do not want to contribute code, there are other ways of contributing. For example, you can provide or update documentation for a project wiki.

1.2. Users, Contributors and Committers

The Eclipse project distinguishes between the following group of people:

  • Eclipse User - Using at least one product, e.g., a JAR file, of the Eclipse project. Eclipse users consume the software created by the Eclipse developers. Users also report bugs and issue feature requests in Eclipse projects they are using.

  • Contributors are individuals who contribute code fixes or make other significant contributions to the project.

  • Committers have write access to the project’s resources (source code repository, bug tracking system, website, build server, downloads, etc.) and are expected to influence the project’s development.

1.3. Relevant Eclipse projects

Eclipse hosts multiple projects but several projects are critical for the development of the Eclipse IDE and RCP applications. These are described here.

1.3.1. The Eclipse Platform project

The Eclipse Platform project provides the core frameworks and services upon which all Eclipse based applications are created. It also provides the runtime in which Eclipse components are loaded, integrated, and executed. The primary purpose of the Eclipse Platform project is to enable other developers to easily build and deliver integrated tools and applications.

1.3.2. The Eclipse Plug-in Development Environment (PDE)

The Eclipse Plug-in Development Environment (PDE) project provides wizards for creating Eclipse RCP applications and plug-ins, editors and other tools to develop Eclipse plug-ins.

1.3.3. The Eclipse e4 project

Eclipse e4 is the name used for the Eclipse Platform incubator project. This incubator is used for exploratory projects relating to improving the Eclipse Platform.

The e4 project includes several technology evaluations. Some of these evaluations have been ported back to the core Eclipse framework. All functionalities described in this document are part of the official Eclipse release, except the Eclipse e4 tooling project.

The Eclipse e4 tooling project provides tools for developing Eclipse 4 applications. They are very useful, but have not yet been added to any main Eclipse project.

1.4. Prerequisites

This tutorial assumes that you have already Eclipse plug-indevelopment experience. See the Eclipse Plug-in development tutorial for details.

2. Getting initial information about an Eclipse project

2.1. The Eclipse project page

Eclipse lists all project repositories under their project page. This page can be found via the main Eclipse projects page. On this website you can search for the Eclipse project you are interested in.

The individual project page contain information about the project. This includes future developments plans, documentation, wiki pages, developer mailing lists and the project charter. If you click on the Learn more in one of the search results you are taken to the project homepage. Click on the Developer resources tab to see all Git repositories of the project.

The following screenshot depicts the website for the JDT UI project.

Eclipse top-level project homepage

2.2. Example: Finding the Git repositories for the Eclipse Platform UI project

The Eclipse platform UI project is responsible for the user interface, runtime, text and user assistant components of the Eclipse platform. In this example search for "Platform UI".

Eclipse Platform UI search result

Click on the Learn more link and select the Developer resources tab.

Eclipse Platform UI developer resources`

2.3. The Eclipse dashboard

The Eclipse foundation provides also Dashboards.

For example http://dashboard.eclipse.org/its-contributors.html gives an overview of Eclipse contributions. The dashboard allows you to drill down as depicted in the following screenshot.

The URL and appearance may still change over time. See Bug 405792 for details.
Project members dash

You can select in the top the sub-project to see. For example the reporting for the Eclipse project is depicted in the following screenshot.

Eclipse project dashboard

2.4. User interface guidelines

Eclipse has a description for its user interface guidelines, it is a bit outdated but still gives an good overview. See Eclipse UI guidelines Wiki.

3. Installation description

3.1. Download the latest integration build

You can download the latest integration build from the Eclipse developer builds webpage. This webpage is despicted in the following screenshot.

Download development builds

This is sometimes necessary to test the latest features or to test a build which is later promoted to M or RC build by the Eclipse platform team.

For most Eclipse projects, you can also use the Eclipse installer. See Using the Eclipse installer for code contributions. The installer will also perform additional configuration and install additioanl plug-ins.

3.2. Install the Git tooling into the Eclipse IDE

After you downloaded a recent build for the Eclipse IDE, you should at least install the Eclipse Git tooling.

4. Exericse: Eclipse user creation and Gerrit server configuration

4.1. Create an Eclipse user account

To contribute to an Eclipse project you need to have valid user credentials. If you already have an Eclipse Bugzilla or Eclipse Forum account, you have already done this step. These systems use the same account.

You can create a new user via the following: Create Eclipse.org user account.

4.2. Sign the Eclipse License Agreement (ELA)

You also need to confirm to the Eclipse foundation that you have the right to contribute your code to the Eclipse open source project. This requires that you sign an Eclipse license agreement (ELA) via a web interface of your user you created.

Eclipse.org user account and click on the Eclipse ECA tab.

The Eclipse ELA FAQ describes the process and purpose of the CLA. At the end this document contains a link for signing the CLA.

In case you contribute to the Eclipse projectduring your work time, ensure that your employer agrees that the code can be contributed.

4.3. Configure your Eclipse Gerrit user

You need to configure Gerrit if you want to use SSH or HTTPS to upload your contributions. The Gerrit user is NOT the same as your Eclipse user. Also, the Gerrit HTTPS password is NOT the same as your Eclipse user password.

To configure your access method open the Gerrit at Eclipse URL and and login with your Eclipse account. This can be done via your registered email address and password via the top right corner of your browser.

Afterwards select Settings as highlighted in the following screenshot.

Gerrit settings for Eclipse

You can either use SSH or HTTPS to push to Gerrit. See Authentication via HTTPS for the configuration of HTTPS and Authentication via SSH for the configuration of the SSH access. If you are not familiar with SSH, the HTTPS authentication is most likely easier to configure for you. If your company is using a proxy, you may have to use HTTPS as a proxy might block SSH.

4.4. Authentication via HTTPS

The web page of the Gerrit review system enables you to generate an HTTP password. Select the HTTP password in the Gerrit user settings and generate a password. This setting is depicted in the following screenshot (the password is obfuscated).

Eclipse Gerrit HTTPS access

Take note or copy the password, as it will be needed to push your changes to the Eclipse Gerrit system. In contrast to SSH, when using HTTPS you will have to enter your password for each operation with Gerrit. You can visit this page later if you forgot the password.

4.5. Authentication via SSH

You need to upload your SSH key to the Gerrit installation so that you can push changes to Gerrit via SSH. Once you have created a SSH key pair, upload your public SSH key to Gerrit to be able to push to it.

Upload SSH key

5. Clone the selected Eclipse Git repository

5.1. Finding the correct Git repository

Ensure you are logged into the Gerrit server webpage. This will enable you to use SSH or HTTPS for cloning the repository.

Go to the Gerrit Eclipse homepage and select the Projects ▸ List menu entry. This opens the Project search page. Here you can search for the project you want to contribute to. In our example we want to contribute to the platform.ui project.

Get URL to clone a Gerrit project

Select the correct project. This opens a new webpage. This page contains links for cloning the Git repository. The selection for HTTPS is depicted in the following screenshot. Please note that the URL for you is different, as it contains your user name.

Get URL to clone a Gerrit project

5.2. Clone the repository via the Eclipse IDE

To clone, select File ▸ Import…​ ▸ Git ▸ Projects from Git ▸ Clone URI.

Get URL to clone a Gerrit project
Get URL to clone a Gerrit project

Enter the URL from the Gerrit webpage in the first line of the wizard. The Eclipse Git tooling removes "git clone" from the clone URI automatically.

Note that the URL automatically includes your user name. This makes it easier to push a change to the Eclipse Gerrit review system. If you clone the repository using the Eclipse Git functionality, your local repository is already configured to push changes to Gerrit, no additional setup step is required. The following screenshot shows this selection, please the depicted user name with yours.

Get URL to clone a Gerrit project

On the next wizard page you can select to clone all branches. The Eclipse platform project uses the master branch for all bug fixes and feature work. Individual bug fixes are downported to maintenance branches but you should always first fix the issue in the master branch.

Finish this wizard by selecting the Next button until you the option Finish option becomes available. You end up with the projects from the repository imported into your workspace.

You can also clone anonymously via Anonymous HTTP, if you just want to play with the source code locally and do not intend to contribute changes. In case you cloned a Git repository without using the Gerrit URL or not via Eclipse Git you have to adjust the push URL to provide Gerrit changes. See [eclipsegerritcontribution_adjustpush] for a description how to do that.

6. Exercise: Install required plug-ins and configure your workspace

6.1. Exercise: Install additional plug-ins via install file

The Eclipse Platform UI team provides a file describing all the plug-ins typically needed for platform development. You can download from the following link this file, stored under version control: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/plain/releng/org.eclipse.ui.releng/platformUiTools.p2f

To install all the development plug-ins import the p2f file via the File ▸ Import…​ ▸ Install ▸ Install Software Items from File menu path.

6.2. Configure API baseline

Eclipse projects frequently needs to ensure that they do not break API, compared to the previous release. For this the API tooling is used, and a missing API baseline is reported as error.

To define and use an API baseline, you need to download and install an official released version of Eclipse. This installation defines your baseline for the API, and you can specify its location in the Eclipse preferences. For this select the Window ▸ Preferences ▸ Plug-in Development ▸ API Baselines menu entry. Here you can define the Eclipse release to use as baseline. With this system, Eclipse can report API breakage by comparing the code in your workspace with the last released code.

For example if you develop for the next Eclipse 4.x+1 release (for example 4.7), you should select the official Eclipse release (for example Eclipse 4.6.1) as API baseline. This way the Eclipse API baseline tooling can check if you break the existing API and if you do this adds error or warning markers to your code. The tooling can also propose quickfixes for such violations.

The following screenshots demonstrates how to configure a API baseline. This assumes that the 4.5 is the latest official release. In the preference press the Add Baseline…​ button.

Setting up the API baseline

Select the folder which contains the latest official Eclipse release, and define a fitting name. Afterwards press the Reset button to use this installation as baseline.

Setting up the API baseline

For detailed information about the usage of the API baseline, see Eclipse Version Numbering Wiki and API Tools.

Handling baseline issues and API is something which the core committers can help with. New contributors can set this error message to warning to have an easy start. This setting is highlighted in the following screenshot.

Setting the API baseline to ignore

6.3. Closing projects

Sometimes a plug-in give you error messages, which you can’t solve. For example, if the plug-in is specific to the Windows operating system API and you are using Linux, you get compiler errors for it.

In this case, right-click on the project and select Close Project from the context menu. This instructs the Eclipse IDE to ignore this plug-in in your workspace.

6.4. Setup for other Eclipse projects

If you planning to contribute to another Eclipse project, please have a look at their contribution guide. This guide is typically available via the corresponding project entry in Eclipse project side.

7. Exercise: make a change and push a review

7.1. Make a code change

Find a very simple change for your first contribution. For example, fix a typo or a compiler warning. Eclipse projects frequently tag bugs with the keyword bugday or helpwanted. These bugs are good candidates for initial contributions.

7.2. Push to the Gerrit review system

Use the Git Staging view to commit your change and to push it to the Gerrit review server.

You need to sign off every commit. The Git functionality in Eclipse simplifies that via the sign-off push button. The Add Change-Id push button allows you to include a Change-Id entry to the commit message. Both buttons are highlighted in the following screenshot.

Eclipse Signed-off-by

The Change-ID entry is initially set to "Change-Id: I0000000000000000000000000000000000000000". During the commit, this is replaced with an ID generated by the Git tooling. Like other Git IDs it is a SHA1 over the content of the commit and the letter 'I' is added a prefix to make it obvious that it is a Gerrit Change-Id and not a Git commit ID.


To get picked up by Gerrit, the Change-Id must be in the last paragraph together with the other footers. To avoid problems do not separate it from the Signed-off-by message with a new-line character.

7.3. Updating the Gerrit review

You may get review comments asking to improve the Gerrit change. Or you find a better way of doing the change. You can update an existing Gerrit review by using the same Change-Id for another commit. The easiest way of doing this is to amend the last commit and push this commit again to Gerrit.

Since the amended commit contains the same Change-Id as the initial commit, Gerrit knows that you want to update this change with the new commit. Also in your local Git repository commit amend replaces the previous commit in your local history (and keep the same parent commit).

8. Identifying who contributes user interface components

8.1. Plug-in Spy for UI parts

You can activate the Plug-in Spy by pressing Alt+Shift+F1 in the Eclipse IDE. It gives you information about the currently selected user interface component. This way you can get immediate access to the plug-in which is currently running.


Click on any of the linked elements to obtain more information about that element. For example, if you click on the contributing plug-in the tool opens the manifest editor for this plug-in.

Press Alt+Shift+F2 and select a menu entry or click a toolbar entry to see information about this element.


8.3. SWT Spy

SWT Spy for Eclipse is a tool that prints out information about the widget under the cursor. Currently, this includes style, layout and parent information. See SWT Development Tools homepage for more information.

8.4. Layout Spy

With Eclipse 4.7 PDE has added the SWT Layout Spy. Press Ctrl+Alt+Shift+F9 on any window to activate it.

Press Select Control to pick a control to inspect. With Show Overlay you activate an overlay that shows an outline around the selected control (red rectangle) and its child (yellow rectangle). You can navigate the controls with Open Child and Open Parent.

To find a control which boundary is misaligned now navigate to a control thats outline is correct but its child isn’t. Check the value of computeSize. If the result of computeSize is correct, the problem is in the parent layout or its attributes. Otherwise the problem is in the child widget.


8.5. Debugging GTK elements with Gtk inspector

GtkInspector is a tool that allows you to debug GTK+ applications. It was introduced in GTK+ 3.14. To start Eclipse with the GtkInspector start it with an environment variable set.

GTK_DEBUG=interactive ./eclipse

You can also start the GtkInspector for an already running program. To do this you have to enable the inspector key bindings. Under ubuntu you might have to install an additional package to make this option available.

sudo apt-get install libgtk-3-dev

Run this command in your terminal to activate the setting.

gsettings set org.gtk.Settings.Debug enable-inspector-keybinding true

After this the keybinding are activated.

Shortcut Purpose


Start GtkInspector


Start GtkInspector

See CSS for GTK and Gtk inspector for more information. == Enable access to plug-ins

8.6. Filtering by the Java tools

The Eclipse Java tools limit the scope of search related activities based on your projects. By default, Eclipse includes elements from opened projects including their dependencies as well as elements from the standard Java library.

For example, the Open Type dialog Ctrl+Shift+T does not find the ISources interface, if it is not referred to by project in your workspace.

As plug-in developer you want to have access to all classes in your current target platform. The target platform is the set of plug-ins against you develop. By default, the plug-ins from the Eclipse IDE installation are used as target platform.

You can include all classes from the current target platform to be relevant for the Eclipse Java tools via the following setting: Window ▸ Preferences ▸ Plug-in Development ▸ Include all plug-ins from target in Java search

How to add all Java classes from the Eclipse target platform to the Java search

9. Find the plug-in for a certain class

You frequently have to find the plug-in for a given class. The Eclipse IDE makes it easy to find the plug-in for a class. Enabling the Include all plug-ins from target into Java Search setting in the Eclipse IDE preferences. Now you can use the Open Type dialog Ctrl+Shift+T to find the plug-in for a class. The JAR file is shown in this dialog and the prefix of the JAR file is typically the plug-in which contains this class.

Open Type Dialog
Plug-in for a Java class

10. Finding classes and plug-ins

10.1. Open Plug-in artifact

Use the Ctrl+Shift+A shortcut to search for an extension point.

Definition and usage of an extension point have different icons. For example, to see which plug-in defines the org.eclipse.menu.ui extension point, enter it in the dialog and select the entry with the blue icon.


Plug-in Search allows you to perform a detailed search for extension points. Select the Search ▸ Search ▸ Plug-in Search menu. You can specify what your are searching for as demonstrated in the following screenshot.


In case you have imported the source code of an Eclipse project into your workspace you can also use the plain text search. Select the Search ▸ Search menu entry and switch to the File Search tab.

As indicated in the following screenshot you can search for a text, use regular expressions and restrict which files to search by specifying a file name pattern. This is a very flexible way to search and allows you to find almost everything.

File Search

11. Eclipse projects responsible for the Java IDE

11.1. The Eclipse project

The Eclipse IDE is an open source (OS) project. Eclipse.org hosts lots of OS projects with different purposes. The foundation of the whole Eclipse IDE is delivered by the Eclipse platform, the Java development tools (JDT) and the Plug-in Development Environment (PDE) project.

All these projects belong to the project called "Eclipse project". The name is a bit strange since nowadays there are many Eclipse projects. But it originates from the fact that these projects were at the beginning the only available Eclipse projects.

These components are bundled together as the Eclipse Standard Development Kit (SDK) release. This is also known as the Eclipse standard distribution. The Eclipse SDK contains all tools to develop Eclipse plug-ins.

In addition to these projects, the platform also has an incubator project called e4 which provides new tools for Eclipse 4 developments. It also serves as a testing ground for new ideas.

11.2. The Eclipse platform projects home pages and Git repositories

The following table lists the home pages of these projects along with the developer pages, which list the Git (and Gerrit) repositories.

Table 1. Eclipse projects
Project Home page Developer pages with Git repositories



Not relevant, as platform is only the top project

Platform UI



Java development tools (JDT)


https://projects.eclipse.org/projects/eclipse.jdt.ui/developer https://projects.eclipse.org/projects/eclipse.jdt.core/developer

Plug-in Development Environment (PDE)



12. Eclipse and tests

12.1. Eclipse projects and their test suite

Eclipse projects typical provide a test suite which is used to validate if changes breaking existing functionality. The Gerrit build validation uses these to validate proposed changes. If changes in the tests are required, you should adjust the tests with the same Gerrit change.

The target of most projects is to run 100% of the test suite during the Gerrit build validation. Due to history reasons that is not yet the case for some projects.

At the time of this writing, most Eclipse tests are based on JUnit 4.x, some are still based on JUnit 5.x.

12.2. Running the Eclipse platform unit tests

12.2.1. Repositories for platform tests

Clone the following Git repositories as these contain the existing unit tests. The clone URLs (these are not URLs for the browser!) are listed below.

  • git://git.eclipse.org/gitroot/platform/eclipse.platform.releng.git

  • git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git

  • git://git.eclipse.org/gitroot/platform/eclipse.platform.runtime.git

Clone them via Eclipse from the Gerrit server as described in [eclipsegerritcontribution_cloneviagerrit_server]. This makes Gerrit contributions to them easier.

12.2.2. Installation requirements

Some tests are using Hamcrest and Mockito. You need to install them into Eclipse from one of the updates sides listed at: http://download.eclipse.org/tools/orbit/downloads/

Install Mockito and Hamcrest

12.2.3. Example: JFace tests

In this section the procedure to run the unit tests of the JFace components is described as an example for running tests from an Eclipse project.

The unit tests for the JFace Bundle are placed in the org.eclipse.ui.tests plug-in. This plug-in includes also several other tests for the Eclipse platform.ui component.

To run theses tests, import the following required plug-ins:

  • org.eclipse.core.tests.harness from the eclipse.platform.runtime repository

  • org.eclipse.core.tests.runtime from the eclipse.platform.runtime repository

  • org.eclipse.test.performance from the eclipse.platform.releng repository

  • org.eclipse.ui.tests from the eclipse.platform.ui repository

  • org.eclipse.ui.tests.harness from the eclipse.platform.ui repository

To test the full JFace TestSuite, you only need to run the JFace-All Tests.launch run configuration from the org.eclipse.ui.tests plug-in.

Screenshot of the JFace JUnit run

12.3. Running the unit tests on a virtual server

The Eclipse platform unit tests starts an Eclipse IDE and visually interacts with it. This screen flickering can be annoying. On Unix based system you can also run the user interface tests with a virtual display. You can of course run the tests without a virtual server but this makes the execution of the tests faster and allows to developer to continue to work on the same machine.

On Ubuntu you can install the virtual server and the client via the following commands.

# install the virtual server and client
sudo apt-get install vnc4server
sudo apt-get install xtightvncviewer (1)
1 The client is not required to run the unit tests but useful in case you want to view the test execution on the virtual server.

You start the server with the following parameters.

# start the server on display #1
vncserver :1 -name testing -depth 24 -geometry 1280x1024

In the Eclipse launch configuration you can define the display which is used for the test execution.

Setting the Display variable in Eclipse

If you are running a Maven / Tycho build from the command line, you can export the display variable.

export DISPLAY=:1

If you want to watch the unit tests, you can also connect to the virtual server via the vncclient.

# connect to the server, IP will be asked

13. Creating a custom Eclipse IDE build

13.1. Building the Eclipse IDE

Eclipse uses a Maven based build system for automated builds using the Maven Tycho plug-in. Using this build system, you can create your custom build of the Eclipse IDE. This approach allows you to add and tests patches based on the latest developments of the Eclipse team. The results of the build are archive files for the different platforms, which include everything to run an Eclipse IDE.

The build procedure might change over time. See Platform build wiki for additional information.

13.2. Requirements

The build of the Eclipse IDE takes around 2 hours on a Core i5 machine with SSD. Approximately 25 GB of free space and 4 GB of RAM are required on the hardware-side. Building of an Eclipse IDE is possible on Windows, OS X and Linux based distributions. The following description is based on Linux.

On the software-side the following software is required:

  • Git

  • Maven Version 3.3.1

  • Oracle 1.8 JDK or higher

13.3. Build instructions

Perform the following instructions to build the Eclipse IDE.

git clone -b master
   --recursive git://git.eclipse.org/gitroot/platform/eclipse.platform.releng.aggregator.git
mvn clean verify -fae

Alternatively, to the aggregated comment for cloning, you can also split the commands:

git clone git://git.eclipse.org/gitroot/platform/eclipse.platform.releng.aggregator.git
git submodule init
git checkout master
git pull --recurse-submodules
git submodule update
mvn clean verify -fae

At the moment the build process generates "dirt", e.g., it generates files which influence the next build. To ensure that the repository is reseted to a clean state, you can use the following commands.

git submodule foreach git clean -f -d -x
git submodule foreach git reset --hard HEAD
git clean -f -d -x
git reset --hard HEAD

To skip the tests use mvn clean verify -DskipTests=true -fae

If you receive java.lang.OutOfMemoryError error during the Maven build, you should increase the memory which is available for the build.

export MAVEN_OPTS="-Xmx2048m"

If the build is successful, the Eclipse SDK is packaged as archive files for all supported platforms. These packages can be found in the Git repository in the eclipse.platform.releng.tychoeclipsebuilder/sdk/target/products/* folder:

13.4. Additional infos about building the Eclipse platform

13.4.1. Eclipse platform Hudson builds

The Eclipse platform builds at Hudson. See Releng builds and Platform builds. This releng build instance is used for the Eclipse SDK build, and the platform instance to validate Gerrit contributions.

13.4.2. Changing build ID

A normal CBI Build shows, "Build id: @build@" in the "About Eclipse SDK" window. To define a custom build id use the buildId parameter and the update-branding-plugins profile.

mvn clean verify -DbuildId=foobar -Pupdate-branding-plugins

To check which properties can be overridden check the properties fields in the eclipse-platform-parent/pom.xml file.

13.4.3. Build single parts of the aggregator

It is also possible to build just single parts of the aggregator repository, by passing the build-individual-bundles profile. The following example shows how to build just the rt.equinox.framework.

cd rt.equinox.framework \
mvn -Pbuild-individual-bundles clean verify

Unfortunately while there are numerous bundles for which the build succeed with this method, there are a couple bundles / features that cannot be built using this method.

13.4.4. Building natives (SWT binary files)

The CBI build does not build natives by default (SWT binary files). Instead, the CBI build simply copies pre-built native files from the swt.binaries repository.

For Windows/Mac/Linux it is possible to force the CBI build to build these natives by passing the -Dnative pointing to the build. For example the -Dnative=gtk.linux.x86_64 parameter in the case of Linux. List of options available at Building natives.

The Fedora project has removed some non Eclipse IDE related plug-ins to speed up the build process. See the Fedora build script.

13.5. "Out-of-office" for Gerrit and Bugzilla

A trick to show other committers and contributors that you are on vacation. Gerrit and Bugzilla do not offer that out of the box, but as a nice trick you can change your last name for Eclipse.org to show that.

Go to Eclipse user profile and click edit for your last name.

Gerrit out of office

After you changed your last name, press btn[Update Account].

Here is an example how this looks like (using another user).

Gerrit out of office
Remember to reset your name, after you returned from vacation.

The Eclipse project allows you optionally to update the last changed date in the copyright header, if you change the file. You can do this manually but the Eclipse releng project also provides tooling for that.

This used to be mandatory but become an optional step in 2016.

You need to install the copyright header tool from the following update site: http://download.eclipse.org/eclipse/updates/4.6

Adjust the number "4.6" to the number matching your eclipse version.

Installing the copyright header tool

After the installation you can select the entry from the context menu of a project or source folder.

Using the fix copyright header tool

14. Appendix: Cloning from the Git server and adjusting the push URL

14.1. Overview

If you cloned an Eclipse Git repository directly from the Eclipse Git server instead of the Gerrit server, you have to adjust the push URL for the usage of Gerrit. For example, you may have found the clone URL on the Eclipse Git web interface.

It is far easier to clone from the Gerrit server via Eclipse, as this does not require you to change the push URL. See [eclipsegerritcontribution_cloneviagerrit_server] for the description how to clone. In case you can use the Gerrit server, this section is not relevant for you.

The push configuration in the following dialog depends a bit if you want to use SSH or HTTPS. If you want to use SSH ensure to use the 29418 port and remove the "gitroot" string from the push-url.

The following screenshot demonstrates that for the Eclipse platform UI Git repository.

Gerrit push configuration

If you want to use HTTPS to push to the Gerrit server, you have to use a push URL with an "r" included (For example https://userid@git.eclipse.org/r/platform/eclipse.platform.ui.git). You need to provide in this case your Gerrit password to push to the Eclipse Git repository. This is depicted in the following screenshot.

Gerrit push configuration

14.2. Gerrit push configuration

The Gerrit server requires that you push using a predefined refspec, called HEAD:refs/for/master. A refspec allows you to configure which remote branch should be used for remote operations.

If you clonee a Git repository managed by a Gerrit server, this push url is already correctly configured in most cases.

The icon for repository configured to be used for Gerrit uses a green icon. Also Gerrit specific commands are added to the repository’s context menu, e.g., Push to Gerrit…​ and Fetch from Gerrit…​ ). In addition, the repository is configured to always add a Change-ID to the commit message. In th following screenshot the repositories configured for Gerrit are highlighted. The eclipse.jdt repository in this screenshot is not configured for Gerrit.

Gerrit Eclipse configuration

If you have to configure the push URL manually, select your remote repository in the Git Repositories_view, right-click on it and select _Gerrit configuration.

Gerrit Eclipse configuration

If you select the origin entry, right mouse click on it and select Gerrit Configuration…​ the entry should look like the following screenshot.

Gerrit Eclipse configuration
For HTTPS access the URL is different.

To validate the push specification, select the highlighted node in the following screenshot and check the _Remote Push Specification_entry in the _Properties_view.

Gerrit Eclipse configuration

15. Using the Eclipse installer for code contributions

You can also use the Eclipse installer (which is provided by the Eclipse Oomph project) to automated some of the steps of code contributions. Please note that the Eclipse installer is currently still under heavy development and the user interface might change significantly.

Download for this, the Eclipse installer from Eclipse installer. Depending your operating system you have to extract it, or you can just run the executable.

Download Eclipse installer

Start it and select the Advanced Mode.

Download Eclipse installer

Select Eclipse IDE for Java Developers.

Afterwards you can select the project you want to contribute to. If this project maintains a correct Oomph configuration will clone the corresponding repository and configure your workspace. The following screenshots are from JDT UI, for which the Eclipse installer configuration is valid as the time of this writing.

JDT contributions via Ooomph 1
JDT contributions via Oomph 1
JDT contributions via Oomph 3
JDT contributions via Oomph 4

You end up with a workspace with the existing Git repositories. After this initial setup you should consult the contribution guide of the project to ensure you know their contribution guidelines.

JDT contributions via Oomph 5

16. About this website

17.1. vogella GmbH training and consulting support


The vogella company provides comprehensive training and education services from experts in the areas of Eclipse RCP, Android, Git, Java, Gradle and Spring. We offer both public and inhouse training. Whichever course you decide to take, you are guaranteed to experience what many before you refer to as “The best IT class I have ever attended”.

The vogella company offers expert consulting services, development support and coaching. Our customers range from Fortune 100 corporations to individual developers.

Copyright © 2012-2016 vogella GmbH. Free use of the software examples is granted under the terms of the EPL License. This tutorial is published under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Germany license.

See Licence.