Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SWT/Devel/Workflow"
m (→Backporting Patches) |
m (→Backporting Patches) |
||
| Line 30: | Line 30: | ||
= Backporting Patches = | = Backporting Patches = | ||
| − | + | It's recommended to backport as following: | |
| − | + | * Create a seperate brach from R_X_maintenance | |
| − | + | * Create a patch that contains changes for your backport | |
| − | + | * 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: | |
| + | * Open Eclipse, checkout "origin/R_X_maintenance" as local branch. | ||
| + | ** Branch 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' | ||
| + | * Manually copy across lines that have changed. | ||
| + | ** Test your patch first with jUnit etc.. Ensure there are no errors in project. (you may need to clean/rebuild/swtjni rebuild bindings) | ||
| + | ** Add changed files to staging area | ||
| + | ** Create new patch (with sign off etc..) | ||
| + | * Right click on SWT git repository and click on "Push to Gerrit" | ||
| + | ** From URI, click on drop down list and select something like: '''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''' | ||
| + | **: (You may need to configure gerrit for pushing to review first). | ||
| − | + | == Note on cherry picking == | |
| − | git push review HEAD: | + | Blind cherry picking can cause problems as it may not pull in all the dependencies that you need for the build to succeed. <br> |
| − | + | 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 | ||
= Mylyn = | = Mylyn = | ||
Revision as of 11:57, 11 July 2016
Contents
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".
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..)
- 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 patch that contains changes for your backport
- 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:
- Open Eclipse, checkout "origin/R_X_maintenance" as local branch.
- Branch 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'
- Manually copy across lines that have changed.
- Test your patch first with jUnit etc.. Ensure there are no errors in project. (you may need to clean/rebuild/swtjni rebuild bindings)
- Add changed files to staging area
- Create new patch (with sign off etc..)
- Right click on SWT git repository and click on "Push to Gerrit"
- From URI, click on drop down list and select something like: 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
- (You may need to configure gerrit for pushing to review first).
- From URI, click on drop down list and select something like: ssh://YOUR_USERNAME@git.eclipse.org:29418/platform/eclipse.platform.swt.git
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
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.