Revision as of 10:05, 7 October 2016

Launching Eclipse with SWT source code

To test SWT snippets, it's useful to launch a child Eclipse with your patch to see how it looks and feels. To do so, under run-configurations, right click on "Eclipse Application" and select "new".

Eclipse Application

Common troubleshooting

Often Eclipse won't launch with various errors. Below are common steps to troubleshoot.

• API Baseline: Make sure API Base line is set. If you updated Eclipse (e.g Luna to Mars), you may need to re-create the baseline.
• Enable Execution Environments: Make sure that relevant Execution Environments are enabled. (1.5, 1.6 etc..)

Eclipse Execution Environments

• Target Platform: Make sure to have an Target Platform set. Try re-creating it with Default for running platform.
• Validate Plugins: In the run-time configuration for a Child Eclipse, under the 'Plug-ins' tab, instead of launching all plugins, try to select only SWT and it's binaries. Try to Validate the setup to see if there are missing dependencies.
• re-create new run-time configuration: Often after updating Eclipse version, I have to create new "Eclipse Application" run time configurations for the child Eclipse to launch propertly

Tips

• Choice of child Eclipse Workspace: Instead of using a blank workspace, copy your exiting workspace, append '-runtime' and use that for your child Eclipse.

Preserving run configurations across workspaces

If you are using the same major version of Eclipse across workspaces, you can copy your run configurations across to prevent losing them. It's highly recommended that you backup your workspace before copying, in case something goes awry.

To find your current launch configurations, navigate to:

 <workspace directory>/.metadata/.plugins/org.eclipse.debug.core/.launches

In this folder, there should be a .launch file for every run configuration created within Eclipse. Copy all these files to:

  <new workspace directory>/.metadata/.plugins/org.eclipse.debug.core/.launches

Launch Eclipse using the new workspace. Open the run configurations dialog, all the old run configurations should be there.

Using Gerrit

Gerrit is used to review your patches. For further information, please see gerrit.

Backporting Patches

It's recommended to backport as following:

• Create a seperate brach from R_X_maintenance
• Create a new patch that contains changes for your backport (I.e, one with a new changeID [Ref 1 below])
• Submit it for review to gerrit. This should link to the bugzilla ticket. (Pushing directly doesn't leave a clean link in Bugzilla bug).

This can be done as following:

• Checkout Maintenance patch
  • Open Eclipse, checkout "origin/R_X_maintenance" as local branch.
  • Create a new branch off of it and it's name should be something of your choosing: ex: R4_6_maintenance_bug_BkP_487757_ScrolledComposite (do not name R4_6_maintenance to avoid confusion with maint branch)
  • Uncheck 'configure upstream for push and pull'

• Apply changes from the desired patch
  • Either:
    • Manually copy changed lines of code, create a new patch.
    • Or just find the desired commit form the git history and click on the cherry pick button in the upper left corner. After cherry picking it, go into the git history, amend your cherry pick and change the 'Change Id' to I000 ... [See Ref 1 below]. Commit and verify that your Change ID is different from the original patch (this is gerrit knows it's a different submission and not a new patch set).
  • Test your patch first with jUnit etc.. Ensure there are no errors in project. (you may need to clean/rebuild/swtjni rebuild bindings)
  • Be mindful of dependencies. For example a patch might depend on a new binding in OS.java from a previous patch that has not been back-ported yet.

• Pushing to Gerrit
  • Right click on SWT git repository and click on "Push to Gerrit"
  • Make sure to change the branch that you're pushing to from master to something like R4_6_maintenance. TIP: you can press ctrl+space in the entry and Eclipse will predict branch names. (And after pushing to gerrit, verify that you're pushing to the maintenance branch not master).
  • Select the correct URI:
    • From URI, click on drop down list and select: ssh://YOUR_USERNAME@git.eclipse.org:29418/platform/eclipse.platform.swt.git
    • (!) Ensure that there is no gitroot in name (as this may be in the default selection), as push to gitroot will fail.

Be attentive:

               ex wrong: ssh://lufimtsev@git.eclipse.org:29418/gitroot/platform/eclipse.platform.swt.git
               ex right: ssh://lufimtsev@git.eclipse.org:29418/platform/eclipse.platform.swt.git
                                                                ^- Platform vs gitroot. Platform is what you want

If 'push to gerrit' is missing, then you may need to configure gerrit for pushing to review first. for 'push to gerrit to work.

It should look like this:

[Ref 1] : New changeID can be created by setting the changeID in Eclipse to: Change-Id: I0000000000000000000000000000000000000000 This works only in Eclipse git. For native git you would have to use custom hooks. Tip: You can toggle the "ammend commit" button to get to a zero Change ID, then copy it back to your change id.

Note on cherry picking

Blind cherry picking can cause problems as it may not pull in all the dependencies that you need for the build to succeed.
With that said, if you find a reliable method to cherry pick a patch instead of copying lines of code across, please document it here.

Note on pushing to branch directly

The following is discouraged, but here for reference purposes.

You can push changes directly to maintenance branch if you have committer rights:

 git push review HEAD:R4_X_maintenance

Note about backporting to versions earlier than n-1

A good explanation has been given by Markus Keller in: https://bugs.eclipse.org/bugs/show_bug.cgi?id=312451#c56

   We only do that rarely, and only after the fix has been backported and tested in the active maintenance branch for a while.
   To backport to out-of-service branches, a few things need to be done carefully:
   - Create a new bug, set its target milestone to the oldest x.y.z+ version, and make sure it depends on the original bug
   - Also backport the fix to *all* maintenance branches that are newer than the one you're interested in. This is important for consumers. E.g. moving from 4.3.2+ to 4.4.2+ must not lose any backported fixes.
   - Make sure you correctly update all necessary bundle and feature version numbers (i.e. all features that contain SWT). E.g. adding 0.0.1 everywhere would be wrong.
   - Test the fix in all branches.

In addition you will need a +1 from an SWT project lead in the bug report.

Mylyn

Nice Video tutorials:

• Mylyn overview: Youtube : Mylyn Overview
• Mylyn, doing code reviews on gerrit Youtube : Code review inside Eclipse with gerrit

 Note, you need to install the 'Gerrit' connector inside mylyn.