contributing e4 tools

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

References

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 .

Contribution Example

In my example I’m contributing by changing the way the editor suggests the Part ID starting from the Label.

[img]

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

[img]

Then I create a branch named as the bug I’m going to work on.

[img]

Code Analysis

Search the class corresponding to the model editor

Search the class responsible to generate the ID

Code Edit

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.

[img/anim]

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.

Concluding

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.

 

Leave a Reply

Your email address will not be published. Required fields are marked *