Copyright © 2009, 2010, 2011, 2012, 2013, 2014 Lars Vogel
|Revision 0.1 - 6.5||14.02.2009 - 13.03.2014||Lars
|created bug fixes and enhancements, platform build and JUnit test contributed by Hendrik Still|
Table of Contents
As the Eclipse project is an Open Source project, it is possible to get the source code, modify it and provide the change back to the project. Eclipse projects typically use a review process based on the Gerrit code review system to review the changes and, if the change fits into the project goal, apply it once it has been polished.
Contributing to an Eclipse project has the benefit of getting feedback directly from the core developers. It also allows developer and organizations to fix bugs which affect them and to drive the project into a desired directions.
The Eclipse project distinguishes between the following group of people:
Eclipse User - Using at least one product, e,g., a
file, of the Eclipse project
Contributor - Submits patches, but is not actively maintaining a project.
Committer - Has been trusted with reviewing patches and the privilege to make changes without going through code review.
The Eclipse IDE is an Open Source (OS) project. Eclipse.org hosts lots of OS projects which different purposes, but 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.
These components are bundled together as the Eclipse 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 mature project, the platform also has the incubator project called e4 which provides new tools for Eclipse 4 development. It serves as a testing ground for new ideas.
The following table lists the home pages of these projects:
Table 1. Eclipse projects
Despite the general assumption that the Eclipse SDK components are development by an army of developers, the actual developer team is relatively small. General information about an Eclipse project can be found under http://projects.eclipse.org/, e.g., via the Who's Involved link you can see the project lead and the main committer. For example, the following screenshot shows the contributions to the platform project, which can be reached under the Eclipse project link
It is possible to see the contributions by individual Git
for example, as depicted in the following screenshot for
project, which can be reached via
Eclipse platform.ui project page.
As these screenshots demonstrate the majority of the Eclipse platform work is done by a few developers. Therefore, new contributors can create a huge impact on Eclipse with contributions.
Eclipse projects use the Git version control system. Eclipse lists all Eclipse Git repositories under the following URL: Eclipse source code repository.
This book is not a Git tutorial, i.e., not all aspects of Git are covered. We only cover the necessary bits of Git to contribute back to the Eclipse project. For more information about using Git see the Git online tutorial or the Eclipse Git tutorial online tutorial.
The Git tutorial is also available as book. See Distributed Version Control with Git: Mastering the Git command line .
To find the URL for cloning the Git repository of a project, you can search in this webpage. For example, if you want to clone the e4 tools Git repository, you can search for e4 and click on the e4.tools repository.
If you click on the project, you see the details of this project, e.g., the commits. On the bottom of the page you also see the URL to clone the repository.
The Eclipse project has a simultaneous release every year at the end of June. In June 2013 Eclipse 4.3 was released.
The Eclipse project creates regular builds of the next releases. You find Stable Builds which are tested by the community. These milestone (ending with M and a number) and release candidate (RC) builds are created based on a predefined time schedule.
Integration (I) and Nightly (N) builds are test builds which are automatically created. They are not manually tested.
In general, milestone and RC builds are relative stable compared to integration builds, but may not contain the latest features and patches.
If you plan to build upon the Eclipse platform additional functionality, you should download the latest Eclipse release. Official releases stable and a good foundation for building your additional functionality on top of it.
To contribute to the Eclipse Open Source project, you need to download one of the recent integration or milestone builds to compile the platform code.
You find the builds for the next Eclipse release under the following URL: http://download.eclipse.org/eclipse/downloads/ .
Download now the latest M-build or RC-build from the Eclipse download page.
It is good practice to use a recent build for Eclipse platform development. While it is possible to use an older build, you typically end up with cryptic error messages.
The following screenshot shows the download webpage of Eclipse. From the displayed selection you can download the latest M build (or RC once available) or an integration or nightly build. Typically M or RC builds should be good enough, except you want to try out bleeding edge things.
Unzip the download and start Eclipse from it.
If you find problems or have an idea on improvements in the Eclipse platform or the e4 tooling, you can open Bug report via the following links: New bug report for the Eclipse platform and New bug report for the e4 tooling project (Eclipse 4 wizards and application model editors)
Once you cloned a Eclipse platform repository, you can import the related projects and starting working on them.
To test the changes, you can start a runtime Eclipse, see Plug-in development for an introduction.
Once done with the fix, you can commit the change locally and push it to Gerrit. See ??? for the required Gerrit setup.
Most Eclipse.org projects and all Eclipse platform projects use the Gerrit code review system for contributions. Gerrit makes the process of contributing relatively simple (after the initial setup). It makes also reviewing these contributions very easy for the Eclipse committer.
In theory you can also provide patches via Bugzilla, but in reality these are rarely reviewed, as the process is more time consuming and less streamlined.
To contribute, you need to configure your Bugzilla and Gerrit user, this process is described in this chapter.
You need to create an Eclipse.org user account to contribute to an Eclipse project. First step is to create a user via the following URL: Create a new Eclipse.org account.
If you already have a Eclipse Bugzilla user or Eclipse Forum user, you have already done this. These users are the same.
You also need to sign a contributor license agreement (CLA). With the CLA you confirm that you have the rights to contribute source code to Eclipse project.
The Eclipse CLA FAQ describes the process and purpose of the CLA. At the end this document contains a link for signing the CLA. You find it under the following URL: Eclipse CLA FAQ.
After signing the CLA you are allowed to contribute code to the Eclipse platform project via Gerrit.
The username registration and CLA signing is not required for cloning the Eclipse repositories and for modifiying the code in your local Git repository. They are only required for contributing a Gerrit review request.
You need to upload your SSH key to the Gerrit installation to that you can push changes to Gerrit via SSH. For this open the following URL: Gerrit at Eclipse.
Login with your Eclipse Bugzilla account and password. Afterwards select Settings as highlighted in the following screenshot.
Select Profile and note down your user. This user is later required for the push configuration.
Once you have your user and CLA, you can clone the Eclipse.org repository of your choice. In this example you clone the Eclipse platform.ui repository.
To find the URL to clone a repository with the correct URL for Gerrit, go to the Gerrit Eclipse homepage and select the → menu entry. Afterwards search for the project.
Once you found a project you can click on it and select SSH or the HTTP tab to see how you can clone that. This is depicted in the following screenshots.
You can also clone anonymously, if you just want to play with the source code locally.
You need to configure the push configuration to push to Gerrit. For this select your remote, right-click on it and select Gerrit configuration .
Skip this section if you clone via Gerrit as described in Section 6.1, “Clone the Eclipse platform Git repository ”.
Alternatively to Section 6.1, “Clone the Eclipse platform Git repository ” you can also clone the Eclipse Git repositories under the following URL: https://git.eclipse.org/c/.
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.
If you want to use HTTPS you have to use a different push URL with an "r" included (For example https://email@example.com/r/platform/eclipse.platform.ui.git). You need to provide in this case your Gerrit password if you want to push to Eclipse.org as depicted in the following screenshot.
Every Eclipse project handles the required commit message a bit different. For platform commits the following format is recommended.
Bug XXXXXXXX - bug title Short description of what the fix contains, or the direction of the fix Change-Id: I0000000000000000000000000000000000000000 Signed-off-by: email-from-the-CLA
The text in the header must match the title in Bugzilla. For example the following is a valid commit message for the Eclipse platform project, (the detailed description has been skipped in this example, as the header make it clear what it is for).
Bug 434846 - Update the system default Locale if the -nl Locale is invalid Change-Id: I6099172a5986e9678a830f84d78b2cdb8c161dc6 Signed-off-by: Dirk Fauth <firstname.lastname@example.org>
Check with the project's contribution guidelines to see if they have preferences on how your commit message style should be.
Every source file contains a copyright header. If you modify the file you should also update the copyright header. If you modify the file, please update the last modified year add yourself to the bug with a reference to the bug. The following listing shows an example.
The file was created in 2008 and last modified in 2014. It was originally created by employees of IBM and also modified by John Doe and he fixed Bug 429728 with it.
/******************************************************************************* * Copyright (c) 2008, 2014 IBM Corporation and others. * All rights reserved. This program and the accompanying materials * are made available under the terms of the Eclipse Public License v1.0 * which accompanies this distribution, and is available at * http://www.eclipse.org/legal/epl-v10.html * * Contributors: * IBM Corporation - initial API and implementation * John Doe <John.Doe@eclipse.org> - Bug 429728 *******************************************************************************/
For new files, use For new files, list "yourself and others" instead of "IBM and others" in the first line.
After you finished the configuration you can push to the Eclipse Gerrit review system. You need to sign off every commit. EGit simplifies that via the sign-of 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.
The Change-ID entry is initially set to "Change-Id: I0000000000000000000000000000000000000000". During the commit, this is replaced with ID generated by the Git tooling.
To get picked up by Gerrit, the Change-Id must be in the last paragraph together with the rest of the footer. Do not separate it from the Signed-off-by message with a new-line character to avoid problems.
The update of the Gerrit review request is the same as described in the general section about the Gerrit usage in this tutorial. Especially follow the guideline to:
Deliver a patch as a single commit (you may want to squash your commits first), because each commit generates a separate change.
If you want to update a Gerrit review request, 'amend' the existing commit - this creates a new patch set in the previous change
You find all open Gerrit review under the following URL: https://git.eclipse.org/r/. Comments from everybody, also non-committers are welcome in Gerrit for review requests.
The most important Eclipse platform.ui repositories are listed below.
# NOTE better get the Git URL via http://git.eclipse.org/r because # that URL contains also your user. That allows you to contribute back easier # Eclipse platform UI repository # contains JFace, Eclipse user interface, example projects # and related tests git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git # Eclipse platform runtime # contains the Equinox runtime and the non user interface related services # and related tests git://git.eclipse.org/gitroot/platform/eclipse.platform.runtime.git
The most important JDT repositories are listed below.
# NOTE better get the Git URL via http://git.eclipse.org/r because # that URL contains also your user. That allows you to contribute back easier # JDT user interface git://git.eclipse.org/gitroot/jdt/eclipse.jdt.ui.git # JDT core git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git
The Eclipse styling is defined in the
eclipse.platform.ui Git repository.
You can change these CSS files or extend them to configure everything to your need. See Eclipse CSS styling for a guide into CSS development and Importing CSS files for a description how to extend CSS files.
In case you are changing the Eclipse platform code you should ensure that the platform still performs as planned. In this case you should run the existing Eclipse platform tests to validate your changes.
Clone the following Git repositories as these contains the existing unit tests.
Eclipse comes with tests for every component. In this section the unit testing of the JFace component will be described.
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 plattform.ui.
To run this tests import the following plug-ins are needed:
It is also required to have a API Baseline configured. You do this by→ → → . For example you can set the baseline again your current IDE installation.
To test the full JFace TestSuite, you only need to run the
run configuration from the
The Eclipse platform unit test start an Eclipse IDE and visually interacts with it. This screen flickering can be annoying. You can use a virtual server and execute the tests on this virtual device.
On Ubuntu you can install the virtual server and the client (which is not required just for the unit tests) via the following commands.
# install the server sudo apt-get install vnc4server # optionally install the client sudo apt-get install xtightvncviewer
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 set the display which should be used.
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 vncviewer
The performance tests allow you to analyze the performance of various actions (e.g.: UIStartup) of the eclipse platform.
To run the tests you have to choose the org.eclipse.core.tests.runtime.perfAllTests.java from the org.eclipse.core.tests.runtime bundle
As result you get detail performance information like the following from the console:
Scenario 'org.eclipse.core.tests.runtime.perf.UIStartupTest.testUIApplicationStartup' (average over 1 samples): System Time: 16.037,55d (no confidence) Used Java Heap: 91,25M (no confidence) Working Set: 446M (no confidence) Elapsed Process: 11,93s (no confidence) Kernel time: 750ms (no confidence) CPU Time: 27,7s (no confidence) Hard Page Faults: 22 (no confidence) Soft Page Faults: 172,24K (no confidence) Text Size: 4K (no confidence) Data Size: 0 (no confidence) Library Size: 3,79G (no confidence)
Eclipse provides a Maven based build system for automated build and allows you to build the Eclipse IDE locally. The results of this build are archive files for the different platforms, which include every thing to run as normal Eclipse IDE. The resulting IDE is based on the source code of the current development status, so results and requirement will change from time to time.
The build itself takes around 2 hours on a Core i5 machine with SSD, so of course time is required for this. Also approximately 25 Gigs of free space and 4 Gigs of RAM are required on the hardware-side. Building of an Eclipse IDE is possible on Windows, OSX and Linux based distributions. This tutorial is tested with Linux.
On the software-side the following programs are required:
Check if your JVM runs in Server mode, by checking the version.
java -version java version "1.7.0_09" Java(TM) SE Runtime Environment (build 1.7.0_09-b05) Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)
You also have to assure that Maven has enough memory, to avoid a
You download the newest version of the source code by cloning the
and it's submodules via Git.
git clone -b master --recursive git://git.eclipse.org/gitroot/platform/eclipse.platform.releng.aggregator.git
To assure that the repository is clean and up to date we execute the following git commands.
mvn -Dtycho.mode=maven org.eclipse.tycho:tycho-versions-plugin:update-pom
The build requires that for the version numbers of the single Maven artifacts and it's Eclipse plug-ins be in sync. But sometimes developers forget to update this version numbers, so we first have to run a Maven goal to correct, eventually existing inconsistencies.
mvn -Dtycho.mode=maven org.eclipse.tycho:tycho-versions-plugin:update-pom
Now we can run the build.
# run the build mvn clean verify
The Eclipse platform has a Hudson build instance which can be found under the following URL: Eclipse platform Hudson. This build instance is currently not used for the main build, only to validate Gerrit contributions. See Bug report for migrating the platform build to Hudson and
To have a reproducible and stable build, it is possible to switch to a specific version instead of using the newest source code. For this the aggregator repository has tags for example every release build. To build e.g. R4_3 you just have to check this specific tag out and start the build like the following:
git checkout tags/R4_3 git submodule update #run the build mvn clean verify
The CBI build still depends on external resource like p2 update sites. From time to time this resources change or will become unavailable. The R4_3_1 tag for example depends on a removed update site, so you have to add the new url to the update site via a parameter to the build:
git checkout tags/R4_3_1 git submodule update #run the build mvn clean verify -Dlicense-repo.url=http://download.eclipse.org/cbi/updates/license/
Currently the Eclipse platform project does not tag the milestone releases. See Bug report. So you have to match the milestone and integration tag manually. You can compare the URL on the Eclipse download page, for example S-4.4M2-201309182000 matches the I20130918-2000 tag.
To speedup the build, it is possible to disable the api-generation.
mvn clean verify -P!api-generation
A normal CBI Build shows, "Build id: @build@" in the "About Eclipse
SDK" window. To define a custom build id use the
parameter and the
mvn clean verify -DbuildId=foobar -Pupdate-branding-plugins
It is also possible to build just single parts of the aggregator
repository, by passing the
The following example shows how to build just the
cd rt.equinox.framework \ mvn -Pbuild-individual-bundles clean verify
The Fedora project has removed some non Eclipse IDE related plug-ins to speed up the build process. See the Fedora build script.
You find a recent version of the e4 tools under the following URL:
The following URL lists the official builds for the Eclipse e4 tooling project.
The e4 tools are also available as via their Git repository.
# Eclipse e4 tooling git clone git://git.eclipse.org/gitroot/e4/org.eclipse.e4.tools.git # Some e4 demos, not required, not always working git clone git://git.eclipse.org/gitroot/e4/org.eclipse.e4.ui.git
Most e4 tools project contain a
file which describes their usage and important classes.
plug-in defines the
extension point, which allows to register editors for new model
You can build the e4 tools locally via Maven Tycho. If you have Maven installed on your machine, the build process is trivial.
Clone the e4 tools project with the following command.
# clone e4 tooling git clone git://git.eclipse.org/gitroot/e4/org.eclipse.e4.tools.git
Afterwards, you can build the e4 tools via Maven on the command line.
cd org.eclipse.e4.tools mvn clean verify
After the build finishes successfully, you find a p2 update site in the following folder.
Eclipse also has a Hudson job configured which runs the daily builds. See https://hudson.eclipse.org/platform/job/deploy-eclipse-e4-parent/
This tutorial is Open Content under the CC BY-NC-SA 3.0 DE license. Source code in this tutorial is distributed under the Eclipse Public License. See the vogella License page for details on the terms of reuse.
Writing and updating these tutorials is a lot of work. If this free community service was helpful, you can support the cause by giving a tip as well as reporting typos and factual errors.
Please consider a contribution if this article helped you. It will help to maintain our content and our Open Source activities.
If you find errors in this tutorial, please notify me (see the top of the page). Please note that due to the high volume of feedback I receive, I cannot answer questions to your implementation. Ensure you have read the vogella FAQ as I don't respond to questions already answered there.