As per reference ( https://wiki.eclipse.org/Platform_UI/How_to_Contribute ) ..
You’ll need to know a few things before you contribute code
L.V.
Environment Setup
Get Eclipse SDK (I-Build or M-Build) from the download page, unpack it and open the workspace you use to contribute.
Download the platformUiTools.p2f provided by the Eclipse platform team and install the required plug-ins from that file, by using the Import menu: Install > Install Software Items.
IDE Properties Setup
on Preferences > General > Workspace, set text file delimiters to Unix line delimiters
on Preferences > Java > Editor > Save Actions, enable the “Perform the selected actions ..” and set:
- Format Source Code > Format Edited Lines: to avoid formatting the whole file, but limit the changes to edited lines.
- Additional Actions > Remove Trailing Whitespaces: to avoid adding trailing whitespaces
Contributing Code
To contribute to Platform UI you will need to get the project source code, stored in eclipse repositories. If you are not a committer and you want to contribute, it is better you use the Gerrit URL to clone the remote repositories. So doing you will be able to get the latest source code from Eclipse master repositories, and commit your changes to Gerrit, so the Committers can validate your work before committing in into Eclipse codebase.
The image above represents the workflow for contribution in 5 steps:
- clone from master to local (use gerrit repo)
- fix the code and commit on local repository (until ok)
- push changes from local repo to gerrit repo
- a committer will review the change (until +2)
- a committer will commit the change
Note: To ensure work on sources> fetch from remote and rebase to fetched master (or pull)
Get source code
Connect to Local Git repositories if they already exists.
Otherwise you will need to clone the needed remote repositories to your local Git folder.
Clone Platform UI Repositories
To contribute to Platform UI you will need to get the project source code, hosted in the three Git repositories below.
https://userid@git.eclipse.org/r/platform/eclipse.platform.runtime https://userid@git.eclipse.org/r/platform/eclipse.platform.ui https://userid@git.eclipse.org/r/platform/eclipse.platform.releng
The above URLs contain with fake Gerrit userid to be replaced with your real one.
The first time I clone repositories I provided Gerrit username and password and I chose to store in Secure Store. So doing the future commit operations will not require the password again.
At the end of the import you can see the Gerrit icon over cloned repos.
After cloning, download psf-import-file , and edit it, by replacing all ssh URLs with the Gerrit URLs containing your real username.
Fix Setup Errors:
To fix API Baseline Errors: unzip latest stable version of eclipse, and set it as baseline for development
- on Preferences > Plug-in Development > API Baseline, set the Eclipse installation directory as API Baseline.
To fix build path problems: install missing JREs (1.6, 1.7 .. ) and reference them.
- on Preferences > Java > Installed JREs. reference missing jre/jdk
Fix Bugs and Contribute
The code contribution are mainly done by fixing bugs, which are listed in eclipse bugzilla (https://bugs.eclipse.org/bugs/)
Usually a contributor starts by fixing very simple bugs (typos, simple files) and proceed toward more complex stuffs.
The Git workflow for contributions is not immediate, and it can be frustrating, especially at the beginning.
Bug Search
below there are some of the common bug searches I perform when I intend to fix bug on Eclipse Platform UI / Runtime
[link] : Eclipse Platform UI and Runtime, with status UNCONFIRMED, NEW, ASSIGNED and REOPENED, ordered by ID desc.
[link] – Eclipse Platform UI and Runtime, UNCONFIRMED, NEW, ASSIGNED and REOPENED, ordered by ID desc, keyword: bugday | helpwanted
Prepare your workspace to Code
Pull latest version from Eclipse remote master to your local repository. Gerrit will work like a proxy (is transparent) when getting the source code from Eclipse master repository.
Branch immediately the repository you will work on. This is very convenient for several reasons:
- working on your bug without risks
- getting back to the master branch just by click on switch branch > master
- work at the same time on multiple bugs without code loss
- allow the committers to examine your code and merge it easily
0 Comments