The Eclipse4 project is a cluster of related technologies for building extensible component-based applications [e4 whitepaper]. This article explains only how to contribute to the E4 Tools project, by using a concrete use case: “contribute to the model editor”.
Clone E4 Tools src from Gerrit
The https URL to connect the E4 Tools repository is reported in the E4 developer resources page.
The basic prerequisites to contribute are to create an Eclipse account, to sign the CLA. Then you can clone the E4 Tools source via Gerrit, by putting your ECLIPSE_ID in the URL. i.e. https://ECLIPSE_ID@git.eclipse.org/r/e4/org.eclipse.e4.tools
After cloning the master branch, is strongly suggested to branch immediately, to ease the development.
Ouch .. now the ModelEditor moved to http://git.eclipse.org/gitroot/platform/eclipse.platform.ui.tools.git
Contribute to Model Editor
The model editor is used to build the application model for E4 Applications. See the screen shot below .
In my example I’m contributing by changing the way the editor suggests the Part ID starting from the Label.
Prepare the Environment
Supposing I already cloned the code from eclipse git repositories, and the local git is configured to use Gerrit, I’m going to prepare my environment for the work
As first thing I pull the latest changes from the Eclipse repositores, by R-Click > Pull
Then I create a branch named as the bug I’m going to work on.
Search the class corresponding to the model editor
Search the class responsible to generate the ID
Change the ID generator, so the ID is lowercase.
Test the code.
Testing in this case is quite easy, it is just launching an eclipse application with all plugin onboard, including the plugin I edited.
To launch Eclipse : run config > clear workspace, goto plugins, select plugins , add required plugins , at voilà. run it.
Once the application is running I perform the specific test, that consists of creating an E4 Application and to see if the editor is now suggesting lowercase IDs.
The patch is working as expected. Is good practice to test different scenarios that can be involved in the change. In this case I check this for the id generation of another component.
Submit the code.
Good, the code is working, ad we think it is tested enough to be submitted. Since gerrit is already configured, we simply need to stage the changes, add the needed information and to commit.
Patience and wait for comments.
After the change is submitted, sooner or later there will be one of the eclipse Committers that will check your changes and who will reject, comment or accept the change
- reject: the change probably brakes some eclipse behavior,
- comment: change is almost ok, but you need to tune the code a little bit. Might be for some trailing whitespace, might be for missing documentation or other reasons. A good practice is to follow Platform UI guidelines, and to check for comments in Gerrit, which is the place where it takes place the discussion about the actual code.
- accept: probably you followed all the standards, and there are no problems with existing Eclipse wokring. therefore the committer decided to promote your gerrit change, to effectively enter the Eclipse codebase. This mean you’re a contributor now.
You just read how to contribute some code to platform.ui.tools, which is a quite important project in the Eclipse Project structure. If you’re interested you can also read how to contribute to E4 Tools, or to platform UI.