- https://github.com/eclipse-platform/eclipse.platform

- https://github.com/eclipse-platform/eclipse.platform.swt

- https://github.com/eclipse-platform/eclipse.platform.ui

- https://github.com/eclipse-platform/eclipse.platform.releng.aggregator

All contributors must have an Eclipse account with an associated Eclipse Contributor Agreement.

<details>

<summary>Details&hellip;</summary>

Create an [Eclipse account](https://accounts.eclipse.org/) if you don't already have one.

All contributors who are not committers on this Eclipse project must electronically sign the [Eclipse Contributor Agreement (ECA)](https://www.eclipse.org/legal/ECA.php) via their [Eclipse account](https://accounts.eclipse.org/).

For more information,

please see the [Eclipse Committer Handbook](https://www.eclipse.org/projects/handbook/#contributing).

To verify the Eclipse Contributor Agreement,

GitHub contributions must use the same email address as your [Eclipse account](https://accounts.eclipse.org/).

If your GitHub account was registered with a different address,

you can [add your Eclipse email address to the account](https://github.com/settings/emails) instead.

Also add your GitHub account name to your [Eclipse account](https://accounts.eclipse.org/) to enable automated management of access rights for Eclipse project members.

You can do this by logging into your Eclipse account,

choosing ["Edit Profile"](https://accounts.eclipse.org/user/edit),

and add your GitHub account name in the social media links section.

If you are a committer in any of the Eclipse projects,

you should receive an email containing an invite to join that project's GitHub organisation within 2 hours.

You can set up a pre-configured IDE for development of the Eclipse SDK using the following link.

[](https://www.eclipse.org/setups/installer/?url=https://raw.githubusercontent.com/eclipse-platform/eclipse.platform.releng.aggregator/master/oomph/PlatformSDKConfiguration.setup&show=true "Click to open Eclipse-Installer Auto Launch or drag onto your running installer's title area")

Every change must be made by creating a pull request from a fork of the main project repository;

see [fork and pull model](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model)

as well as [working with forks](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks) in the GitHub documentation.

You will need a fork for each repository to which you wish to contribute.

<details>

<summary>Details&hellip;</summary>

Whenever changes are pushed to the main project repository,

you can click _Sync fork_ in the forked repository to get the latest source code from the main project repository.

_With this option, you can easily retrieve the most recent changes from the main project repository by simply pulling the `master` branch, as your default remote repository will be the main project._

Clone the main repository to your Eclipse workspace or,

if you use the Eclipse installer as explained in [Creating an Eclipse Development Environment](#creating-an-eclipse-development-environment),

the repository is already cloned that way.

The repository URL can be found by clicking the _<> Code_ button on the top right of the _<> Code_ tab within the GitHub page for the main project repository.

When you clone the repository,

it will automatically be added as the "origin" remote to your local clone.

To this end,

add the forked repository as an additional remote called "fork" (or whatever you like):

Whenever the `master` branch of the main project repository changes,

pulling the `master` branch of your local clone will give you the current state.

In case you have created a branch and committed changes to it,

you can rebase it onto the updated `master` branch.

Clone the forked repository to your Eclipse workspace or,

if you use the Eclipse installer as explained in [Creating an Eclipse Development Environment](#creating-an-eclipse-development-environment),

you have to change the URL for the repository during the setup.

The repository URL can be found by clicking the _<> Code_ button on the top right of the _<> Code_ tab within the GitHub page for the forked repository.

When you clone the forked repository,

it will automatically be added as the "origin" remote to your local clone.

To this end,

add the main project repository as an additional remote called "upstream":

Whenever the `master` branch of the main project repository changes,

you have to synchronize the `master` branch of your fork.

Go to the GitHub page of your forked repository and click _Sync fork_.

You can then pull the `master` branch of your local clone to retrieve the current state.

In case you have created a branch and committed changes to it,

you can rebase it onto the updated `master` branch.

</details>

You will need to create a pull request in order to contribute.

<details>

<summary>Details&hellip;</summary>

When you have set up a fork of a repository to which you wish contribute and prepared a local clone for it,

you can make changes,

commit them,

and propose them via a pull request according to the standard ["pull requests from a fork" workflow](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork).

In the following,

the workflow is sketched with some specific information for the Eclipse platform projects.

1. **Preparing the PR:** Create a branch in your fork and apply the desired changes to it.

Push the branch with the changes to your forked repository (not to the original upstream project repository).

- Make multiple commits if necessary as history can be retained,

but note that you will usually be asked to combine your changes to a single commit per pull request.

So keep changes as small as possible and try to split them up.

2. **Creating the PR:** Open the page of the forked repository in your browser,

switch to the branch where the fix is developed.

Click the _Contribute_ button to start the _Open Pull Request_ workflow.

- On the new page verify the target branch is the `master` branch of the main project repository.

- Verify that the list of commits contains the changes you intend to merge.

- If you are a committer,

you can add reviewers if you want certain people to review a change.

If you leave this empty,

anyone from the project team will review.

3. **Updating the PR:** To update your pull request,

you can push more commits to the same branch in your fork.

They automatically get added to the pull request (and trigger a new round of builds and reviews).

You can also amend your previous commits and force push them to your branch.

you could provide 2 separate commits in the same PR:

one with the functional changes (i.e., in the code) and one with the version bump (i.e., in the Manifest/POM files).

This is not a rule but,

if necessary,

it would help cherry-picking commits when merging your PR,

and avoids problems if there is ever a need to revert the code changes.

- Reviewers can review the pull request on the GitHub website or fetch the PR using the _Fetch GitHub PR_ menu entry in the _Git Repositories_ view inside the Eclipse IDE.

- Every PR is automatically verified to check that contributors have a [valid Eclipse Contributor Agreement (ECA)](#setting-up-your-eclipse-and-github-account).

- What does a valid PR look like? (Checklist)

These are the basic criteria that need to be fulfilled for a PR to be considered valid.

- All checks need to pass.

- If there are other (obscure) errors in the checks,

please find them (read the logs) and actively ask what is happening and how to fix them.

- The commit text should be well-written (see [Commit Message Recommendations](#commit-message-recommendations)).

- If tests were added,

they should meet the following criteria:

- They should **run**: check the logs and make sure they are being executed.

- They should **pass**: do not add broken tests.

- If the PR has been reviewed and the reviewer left some comments,

address them and clearly document what you did.

If you have simply done the obvious thing recommended by the reviewer,

a "thumbs up" emoji is sufficient and helps avoid unnecessary notifications.

Please resolve each review comment when it has been addressed by a follow up commit.

5. **Merging the PR:** Once the PR is approved,

it can be merged by a committer.

- One of two options can be selected,

based on what fits best given these criteria:

- _Rebase and Merge_: retains all commits separately; useful when developing a feature consisting of multiple independent commits.

- _Squash and Merge_: all commits in the PR get squashed into a single commit; useful to avoid separate "fix comments" commits.

- Your fork is now _out-of-date_ with the main (upstream) project repository.

In case the "origin" remote of your local clone is the forked repository,

You can either use the _Sync Fork_ function on GitHub to update the fork and pull the `master` branch to your local clone,

or pull the latest changes from "upstream" (the main project repository) into your local repository.

</details>

<details>

<summary>What to do&hellip;</summary>

A draft PR indicates that:

- The changes are **not yet ready for submission/merging**,

e.g., work is still in progress, tests are incomplete, or functionality is not fully working.

- You are **seeking early feedback** from the community on your approach,

design decisions,

or implementation.

**Important:** Clearly state in the PR description what kind of feedback you are seeking,

as draft PRs may be overlooked until marked as ready for review.

- You may need **help or guidance** to resolve specific issues or to complete the work.

- You want to **share your progress** with others who might be interested or affected by the changes.

<details>

<summary>What not to do&hellip;</summary>

A draft PR is **not**:

- A place to dump incomplete or unclear changes without context.

Every PR, including drafts, should have a clear purpose and description.

- A shield against comments or reviews.

Marking a PR as draft does not mean "leave me alone" – it means you welcome early feedback and collaboration.

- A substitute for local development or working in a private branch.

If you're not ready to share your work or discuss it with others,

keep it in your local repository or in a branch of your fork without creating a PR.

</details>

<details>

<summary>Best practices&hellip;</summary>

Even when marked as a draft,

your PR should meet these basic requirements:

- **Clear intent and description**: Explain what you are trying to achieve,

why the changes are being made,

and what the current state is.

- **Understandable changes**: Others should be able to understand what you have done so far and what remains to be done.

Consider using a task list in the description to track progress.

- **Specific questions or requests**: If you need help or feedback on particular aspects,

clearly state what you need,

e.g., "I'm unsure about the approach in XYZ.java" or "Tests for feature X are still missing".

- **Reasonable completeness**: While not everything needs to be finished,

the PR should represent a coherent chunk of work that others can review and comment on meaningfully.

When your draft PR is ready for final review,

convert it to a regular PR using the "Ready for review" button.

At that point it should meet all the criteria from the checklist above.

</details>

Please use a commit message with a concise summary,

a description,

and a link to an issue,

if there is an associated issue.

<details>

<summary>Details&hellip;</summary>

Example:

The issue title must be a concise summary of the change.

A more detailed description is provided in the body.

Please do not forget to add the issue URL to the commit message.

This is used to link with the GitHub issue.

</details>

<details>

<summary>Details&hellip;</summary>

Due to current limitations, using this directly against the base repository has some drawbacks:

so the branch is created directly on the repository which is against the recommended fork-based workflow.

- Copilot currently cannot squash and force push a branch.

- GitHub does not support filtering of individual notifications,

due to the high cadence and the incremental work mode in some cases,

this can easily flood the inbox of subscribers of the repository.

- If the task is not properly written or the problem is too complex,

it can result in creating something off the track that needs to be discarded and then iterate again which results in more churn.

- Instead of assigning Copilot an issue,

simply reference the issue in the prompt,

e.g., `Analyze and propose a fix for <link to the original issue>`.

- If you are happy with the result or would like to further refine it yourself,

just fetch the branch from your fork,

squash all commits,

remove unnecessary files and force push the result to a new branch,

e.g., usually Copilot creates `copilot/fix-for-issue-123` so just push it as `fix-for-issue-123` and then open a PR against the repo as usual.

- Usually you want to leave Copilot as the author and you as the committer,

unless you have significantly rewritten the results,

e.g., if it was mostly a research task and you did the actual implementation.

</details>

Please respect the time and attention of the humans involved in the review process,

and reduce the load on the shared build infrastructure that verifies each commit.

Use your fork for drafting a pull request and for initial copilot reviews.

Create a pull request only after you have personally verified the quality.

<details>

<summary>Details&hellip;</summary>

Typically a pull request should not be opened while the content is effectively a draft.

It should be fully reviewed by you as a human author,

and you should have high confidence that the work is complete and ready for the review of another human being.

Content that is still being refined,

or is still being reviewed in source form by automated (non-human) reviewers,

should not be pushed to the upstream repository.

The goal is to reduce notifications to the repository followers and to avoid thrashing the shared build infrastructure.

Every push to an upstream PR triggers the verification builds and notifies all subscribers.

The number of concurrent jobs on GitHub-hosted runners is [limited](https://docs.github.com/en/actions/reference/limits#job-concurrency-limits-for-github-hosted-runners),

so intermediate states queue up builds for everyone.

so the motivation is less noise and particularly less shared ci.eclipse.org load.

Therefore it is generally preferable to get AI feedback before you open the PR against the upstream repository:

1. **Locally (preferred):**

Run the [build on the command line](#command-line-builds) and use the local review features of your AI tool,

e.g., the [GitHub Copilot CLI](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/overview) offers the `/review` command to run a code review agent on your local changes.

If something does not work locally,

please let us know.

Workflows [don't run in forked repositories by default](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflows-in-forked-repositories),

you must enable GitHub Actions in the **Actions** tab of your fork.

If you want to use web-integrated tools like [Copilot code review](https://docs.github.com/en/copilot/concepts/agents/code-review),

you can open a PR against your own fork.

Iterate locally first,

then push to your fork,

and open the PR against the upstream repository only at the end.

</details>

It is sometimes beneficial to build on the command line as this is how we also execute the verification builds.

Moreover some tests might not run at all in the IDE if they require a very specific setup.

If you want to produce an update site from your changes or want to have local build artifacts of your changes,

you will need to do this on the command line.

<details>

<summary>Required tools&hellip;</summary>

We are using [Apache Maven](https://maven.apache.org/index.html) for building the sources,

usually it is fine to just use the [latest release](https://maven.apache.org/download.cgi) you can use whatever [install method](https://maven.apache.org/install.html) that is sufficient for your system.

</details>

<details>

<summary>Running the build&hellip;</summary>

Most project repositories are already set up so that you can run `mvn clean verify` directly.

One exception is the [aggregator build](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/) that builds all projects together and requires [special attention](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/?tab=readme-ov-file#how-to-build-the-eclipse-sdk).

</details>

<details>

<summary>Tips and tricks&hellip;</summary>

- If your **changes do not seem to be applied** this is usually a sign that you forgot to increment the version of the bundle,

or haven't committed (you don't need to push) your changes;

in which case the baseline replace might come into effect.

You will see a warning in the log like this `[WARNING] <project name>: baseline and build artifacts have same version but different contents`.

- If you just want to **build one specific module**,

this is usually possible without special consideration.

Just keep in mind that if the tests are separated from the module you have changed you need to build both of them or the whole reactor.

For example you can run the tests and the bundle under test with the command `mvn clean verify -pl :<name of the bundle under test>,:<name of the test bundle>`; one specific test can be run by adding `-Dtest=<fully qualified class name of test>`.

- You can perform a **quick run** to check everything compiles with `-DskipTests` in combination with `-T1C` — this can really speed things up; just keep in mind that the tests are not executed.

- If you want to **make sure you didn't break the API** you can specify `-Papi-check`.

- If you want to **check the javadoc** (JDT currently [not find all issues](https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1858) in the IDE) you can specify `-Pjavadoc` additionally `-DfailOnJavadocErrors=true` will even fail the build,

you can even [try to fix them](https://maven.apache.org/plugins/maven-javadoc-plugin/fix-mojo.html) automatically by adding 'javadoc:fix' to your command

</details>

- For official announcements,