Home Tutorials Training Consulting Books Company Contact us

Get more...

Training Events

This tutorial explains how to contribute to the Eclipse IDE. This tutorial assumes that you have already Eclipse plug-in development experience. See the Eclipse Plug-in development tutorial for details.

1. Contributing to the Eclipse IDE

The Eclipse IDE is an open source project in which companies and individuals advance the code. Everyone has read access to the code repositories. You can clone the source code, modify it and provide the change back to the project. Most Eclipse projects use a code review process based on Github pull requests. Some use the Gerrit code review system.

Contributing to an Eclipse project 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 the Eclipse core IDE using Github pull requests. 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.

2. Exercise: Install the latest Eclipse integration build

Eclipse platform and Java tool development usually works best with using the latest integration build, a build created daily based on the master branch of the repositories.

Download the latest integration build from the Eclipse developer builds webpage. This is necessary to use, test and enhance the latest features and API.

This webpage is despicted in the following screenshot.

Download development builds

You can use also use the Eclipse installer, see https://www.vogella.com/tutorials/EclipseGit/article.html#usingoomph for most projects to setup an IDE and workspace. This setup automates multiple steops but might sometimes be outdated.

3. Approach in this tutorial

In the following exercises you:

  • Create an Eclipse user

  • Create a Github user

  • Clone a Eclipse repository and setup it for code contributions

4. Exercise: Configuring your user

To contribute to the Eclipse IDE you need two users:

  • A user on Eclipse.org to ensure that that you are allowed to contribute code to the project

  • A user on Github to provide your changes to the project via pull requests

4.1. Create user for Eclipse.org

To contribute code to Eclipse, you need to have a valid user for the Eclipse website. If you do not have yet a user, create now a Eclipse.org user account.

You need to confirm that you have the right to contribute your code to the Eclipse project. For this, sign the Eclipse license agreement (ELA) via a web interface of your user you created. Eclipse.org user account and click on the Eclipse Contributor Agreement link.

4.2. Create a user for Github

See Github user creation to learn how to create a user and an access token.

5. Exercise: Fork and clone the platform UI repository

5.1. Finding the correct Git repository

The Eclipse SDK uses four projects with multiple repositories for its content:

Here you can search for the project you want to contribute to. In our example we want to contribute to the platform.ui project which is located https://github.com/eclipse-platform/eclipse.platform.ui Eclipse uses the Github standard process of contributing, you fork a repository on the server, clone it locally, push to your fork and create a pull request.

5.2. Fork the repository on Github

Forking is the process of making a copy on Github of a repo to which you have access. Go to https://github.com/eclipse-platform/eclipse.platform.ui and press the Fork button.

eclipse fork10
eclipse fork20

5.3. Clone the repository via the Eclipse IDE

Use Ctrl+3 (or Cmd+3) and type Clone a Git repository in the dialog.

github platform clone10

Enter the URL to your Github fork in the first line of the wizard.

github platform clone20

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.

5.4. Install test feature

Install the test feature via Window  Install New Software as the test plug-ins require s plug-ins. To get the latest test bundle, use the https://download.eclipse.org/eclipse/updates/I-builds update site.

platform test feature installation10

Restart your IDE afterwards.

5.5. Import project from the Git Repositories view

Use Ctrl+3 (or Cmd+3) and type Git Repositories in the dialog to open the corresponding view. Select your clone Github repository, right-click on it and select Import Projects to import the projects.

5.6. 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.

5.7. Start a runtime Eclipse

Pick one of the imported projects and error free projects in your workspace and select Run As  Eclipse application. This should start a runtime Eclipse.

You can now modify your code, start the runtime Eclipse again and test the runtime behavior in the new runtime Eclipse.

Exercise: Configuring the API baseline

The Eclipse platform project avoids unplanned API changes. To avoid API breakage the API tooling is used which requires an API baseline which is used for comparison.

To define API baseline, you download and extract the latest released version of Eclipse from https://download.eclipse.org/eclipse/downloads/. For example lets assume we are in Oktober 2021. As you are developing at this point in time for the 2021-12 release (with the internal version number 4.22), select the 2021-09 release as API baseline.

If your workspace, which you are using to change the Eclipse platform code, you need to point the API tooling to this download. For this, select the Window  Preferences  Plug-in Development  API Baselines menu entry. With this setting, Eclipse compare the API in your workspace with the API in the official release and report can report API breakage.

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 for a workspace.

Open Window  Preferences and search for API Baselines. In the corresponding preference page, press the Add Baseline…​ button.

Setting up the API baseline
Setting up the API baseline
Setting up the API baseline

Select the folder which contains the official Eclipse release, and define a fitting name. Afterwards press the Refresh 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. Exercise: make a change and push a review

6.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.

6.2. Push to your Git fork

Use the Git Staging view to commit your change and to push it to your fork on Github. Push to branch name of your choice. Now go to the Github web page and create a pull request for your change.

6.3. Updating the pull request

You may get review comments asking to improve the change. Or you find a better way of doing the change. You can update an existing branch on your for by force pushing to it. The easiest way of doing this is to amend the last commit and force push this commit again to the same branch on your fork.

6.4. Verification failures due to missing version update

For every Eclipse release the version number of the plug-in needs to be increased, as Eclipse follows sema ntic versioning.

The x.y.z.build version of the MANIFEST.MF follows the following pattern:

  • major - increase if you break consumer and implemetors of the API

  • minor - increase if you break implementors for the API

  • service - if you change internal stuff, e.g., non API or Javadoc

  • build qualifier - will be filled in by the build system

The verfication build of the platform will verify if an increase of the version is necessary. If this is necessary you see the following error message:

[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:1.3.0-SNAPSHOT:compare-ver sion-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.ltk.core.refactoring: Only qualifier changed for (org.eclipse.ltk.core.refactoring/3.9.100.v20181024-1316). Expected to have bi gger x.y.z than what is available in baseline (3.9.100.v20180828-0626) → [Help 1]

If you see this error you need to update at least the service version by 100 for any platform project.

This involves:

  1. Changing the Bundle-Version in the MANIFEST.MF file

    Bundle-Version in MANIFEST.MF
  2. Changing the <version> in the pom.xml file

    version in pom.xml

6.5. Providing backports to maintenance releases

The Eclipse platform project is currently developing in the master branch. If a bugfix or feature should be provided via a maintenance release, it is backported.

To backport, you:

  • Cherry-pick the commit onto a branch which is based on the current maintenance branch

  • Push the Gerrit review to the maintenance branch via the refs/for/your_maintenance_branch refspec.

This is demonstrated by the following screenshots.


7. Tools to analysis Eclipse code and behavior

7.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.

7.2. Model spy for the application model

The application model of an Eclipse application is available at runtime. The application can access the model and change it via a defined API.

To analyzing and modify the runtime model, you can use a test tool from the e4 tools project which allows modifying the application model interactively. This tool is called Model Spy (used to be called: Live model editor) and can be integrated into your RCP application. Most changes are directly applied, e.g., if you change the orientation of a part sash container, your user interface is updated automatically.

In the model spy, you can select a part in the application model, right click on it and select Show Control to get the part highlighted.

Model spy and the Eclipse IDE

If installed you can also use the model spy to see the application model of the running Eclipse IDE itself. You can open it via the Alt+Shift+F9 shortcut.

If you modify the Eclipse IDE model, you should be careful as this might put the running Eclipse IDE into a bad state. To fix such issues, start the Eclipse IDE from the command line with the -clearPersistedState parameter.

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


7.4. SWT Spy for widget information

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.

7.5. Layout Spy for layout information

As of Eclipse 4.7 you also have a 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.


7.6. Preference Spy for tracing preference changes

The Preference Spy provides a way to trace preference value changes. The Preference Spy is part of the PDE tools.

You can open the Preference Spy with the Shift+Alt+F11 shortcut or via Window  Spies…​  Preference Spy…​_.


In the upper right corner, you see the controls for the Preference Spy. They can be used to…​

  1. toggle between flat and hierarchical layout

  2. show all preferences

  3. toggle tracing preferences changes

  4. expand all preferences

  5. collapse all preferences

  6. remove entry from view

  7. remove all entries from view

On the picture you see the hierarchical layout. Furthermore tracing of preferences changes is enabled. The bold entries depict the recently changed preferences with the old and new value. The non bold entries are any other preferences that can be shown by pressing the button to show all preferences (2).

7.7. Access the current call stack to find the relevant code

To see the call stack of a runtime Eclipse, you start an runtime Eclipse in the debug mode. Once you reach the relevant state, press the Suspend button. Afterwards you can expand the call stack and see the code you are looking for.

suspend thread10

This makes it very easy for example to find the code which opened a dialog.

suspend thread20

7.8. 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 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.

8. Exercise: Using the model spy

In this exercise you will add the model spy to your Eclipse application. The model spy is a development tool to see your current application model and also to modify it at runtime.

The spies are debug tools and not intended to be used in a productive application.

8.1. Add the spies to your target platform

Add the spy feature to your target platform to be able to add them to your product. Add new entries to your target platform to make the spies available.

You may have multiple additional entries in this file, for example if you added the JDT tools to your target file, you would also see an entry for org.eclipse.jdt.feature.group.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde version="3.8"?>
<target name="target-platform">
        <!-- all your old entries should stay here -->

        <!-- add these new entries, we use a new location entry but you could also add them to the existing entry-->
        <location includeAllPlatforms="false" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
            <repository location="https://download.eclipse.org/releases/latest"/>
                 <unit id="org.eclipse.pde.spies.feature.group" version="0.0.0"/>

Reload the target platform after this change.

8.2. Add a top level menu entry to your window in your RCP application

Add a main menu to your window. This can be done via the Main Menu property on the window application model.

modelspy menu10

Ensure the id for this menu is set to org.eclipse.ui.main.menu.

modelspy menu20

8.3. Add the model spy to your runtime configuration

Open the run configuration of your product via the Run  Run Configurations…​ menu entry.

Switch to the plug-ins tab and select to Launch with: Plug-ins selected below

adding liveeditor06

Add the org.eclipse.pde.spy.model plug-in and its dependencies to it.

Adding the live editor to a run configuration

If you use the filter you have to remove it before the Add Required Plug-ins becomes active again.

Adding the live editor to a run configuration

Press the Validate button to ensure that all dependencies are included.

Afterwards press the Apply and Run.

8.4. Use the model spy

After you have added the new plug-ins to your run configuration press the Run button in the run configuration you just added.

Do not start the application now via the product. Starting via the product resets your changes in the runtime configuration.

INFO: See the next section for possible errors in case you cannot open the model spy in your application.

Use the Window  Spies menu entry to display the model spy.

using model spy

Use the model spy to change the runtime application model.

If you set the toBeRendered element to false, the element will be destroyed. If you do this for the application or the last window the application will shutdown. If you do not use the -clearPersistedState flag, this state will be restored at the next start, e.g., at restart your application will shutdown again.

For example, add a part (with a label) or change the size of the window. All changes should become immediately visible (except changes for new menu entries, due to a bug).

8.5. Possible issue with the model spy not showing up in your application

If the model spy is not available in your started application, check that you:

  • used org.eclipse.ui.main.menu as ID for your top level menu, this is the hard-coded ID the model spy contributes to

  • pressed the Add Required Plug-ins button after and the model spy plug-in to the runtime configuration

  • did NOT start via the product, as this would update the runtime configuration based on the product and therefore remove the model spy again

  • manually added org.eclipse.pde.spy.core if you use a release before Eclipse 2022-09, ensure, the Add Required Plug-ins button will only add this plug-in after the 2022-06 release.

8.6. Cleanup - remove model spy from your run configuration

After testing with the tool enabled, start your application again from your product configuration file to remove the model spy plug-in from your run configuration.

If you leave the model spy included in your run configuration, it might cause side effects. For example, in the past it created exceptions if key bindings were present in the application.

9. Optional Exercise: Using the context spy

The spies are debug tools and not intended to be used in a productive application. So it might happen that this exercise does not work, or that you see additional exceptions in your log file, caused by the tool.

9.1. Description of the context spy

The context spy allows you to see the key/value pair which are available for dependency injection. If you are using an explicit target definition file, the spies must also be added to the target definition file.

9.2. Add the context spy to your runtime

Add org.eclipse.pde.spy.context to your launch configuration via Run  Run Configurations…​ and the Plug—​ins tab.

Afterwards press the "Add required button".

context spy10

Use the Window  Spies menu entry to open the context spy.

After you finished testing with the context spy, please remove it again from launch configuration. The spies are debug tools which may result in strange side effects.

10. Enable access to plug-ins

10.1. 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

11. 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

12. Finding classes and plug-ins

12.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 you 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

13. Eclipse projects responsible for the Java IDE

13.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.

13.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)



14. Eclipse and tests

14.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.

14.2. Running the Eclipse platform unit tests

14.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. This makes Gerrit contributions to them easier.

14.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: https://download.eclipse.org/tools/orbit/downloads/

Install Mockito and Hamcrest

14.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

14.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 tightvncserver
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

15. Creating a custom Eclipse IDE build

15.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.

15.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

15.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 reset 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:

15.4. Additional infos about building the Eclipse platform

15.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.

15.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.

15.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.

15.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.

16. Tips and tricks

16.1. "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.

To apply the change in your address data, you need to logoff and login into Bugzilla.

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: https://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

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

17.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. 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

17.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 clone 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

18. 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
Legal Privacy Policy Change consent