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.

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

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.

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.

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

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

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.

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.

Restart your IDE afterwards.

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.

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.

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.

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.

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.

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.

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:

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:

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:

This is demonstrated by the following screenshots.

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.

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.

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

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.

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.

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…​

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

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.

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

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.

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.

Run this command in your terminal to activate the setting.

After this the keybinding are activated.

See CSS for GTK and Gtk inspector for more information.

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.

Reload the target platform after this change.

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

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

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

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

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

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

Afterwards press the Apply and Run.

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

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.

Use the model spy to change the runtime application model.

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

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

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.

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.

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

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

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

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.

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.

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

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.

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

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.

You start the server with the following parameters.

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

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

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

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.

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:

Perform the following instructions to build the Eclipse IDE.

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

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.

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

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:

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.

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

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

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.

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.

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

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.

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.

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.

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 .

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

To validate the push specification, select the highlighted node in the following screenshot and check the Remote Push Specification entry in the Properties view.