1. Gradle and Eclipse RCP Ned Twigg
All code examples available here

2. Why Gradle Relative to Ant / Maven
Drastically lower activation energy to begin to automate something which doesn’t already have a plugin.
Relative to Make / Batch / Shell / Scons / etc
You have the power of the entire JVM ecosystem behind you
Write-once-run-anywhereish
List of things in our build that started out as a dozen lines of Groovy, and grew into independent projects
A system for setting up our TeamCity / Artifactory / GitBlit server
A system for distributing VPN credentials
An RCP-aware obfuscator
Spotless, a format enforcement plugin
Goomph, a bunch of SWT and RCP build utilities

3. About the author
At DiffPlug, we build and ship an Eclipse RCP application to customers on Windows, Mac, and Linux.
Possible to ship several beta releases per day (with fast incremental- update) for tight iteration with a customer.
We have unit tests and UI integration tests which run on a CI server
One-click and a new developer has the code and a working IDE
One-click and the application installers, update sites, and auto- updater are all uploaded and live.

4. What’s missing in Gradle core (we’ll address each in turn with either a plugin or a workaround)
Consume dependencies from P2
Gradle can speak Ivy, Maven, and flatdir, but not P2
Generate OSGi metadata
Lots of ways to generate OSGi metadata, with varying levels of automagic
Difficult to sync MANIFEST.MF with Eclipse
Setup a targetplatform
Need to ensure Eclipse and Gradle are working from the same stuff
Run Eclipse headless build

5. Fantastic work by Andrey Hihlovskiy
Kickstarted SWT/Eclipse/RCP development in Gradle world
Addresses every problem in the last slide
Includes “the whole kitchen sink”
Does lots of stuff whether you ask it to or not
Very difficult to do “clean” OSGi (lots of Require-Bundle)
Not abandoned, but not heavily developed either
We have shipped applications with it in the past, but have chosen to deprecate it entirely in favor of a collection of plugins with a tighter focus.

6. 1. Consume dependencies from P2
Nobody is working on native support at the moment
stalled gradle-dev discussion about adding support for P2
V-RizQg/swXSWeGmqboJ
Workaround A - pioneered by Wuff
Download an Eclipse SDK
Put all of its jars into a local maven repository
Use the Require-Bundle metadata to populate maven dependencies (ignores Import-Package)
Workaround B - must specify all jars (and their versions) manually

7. 2. Generate OSGi metadata
Gradle ships with an OSGi-generator, and there are several on GitHub
All have bugs, except
Just takes bnd-directives
Add a task to the end of jar which copies to your working directory from the compiled jar
TODO: include a demonstration snippet, or build it into Goomph

8. 3. Setup a targetplatform
Create a ‘targetplatform’ project, and apply bnd-platform to it.
Declare all of your plugins as a dependency of targetplatform
The plugin will create a directory which contains every dependency in your project.
Dependencies which already have OSGi metadata will be left unchanged
Dependencies which don’t have OSGi metadata will be wrapped by bnd
You can specify custom bnd settings, either to wrap non-OSGi bundles or to modify existing OSGi bundles

9. 4. Run Eclipse PDE headless
PdeProductBuildTask
PdeAntBuildTask
P2DirectorModel

10. Goomph – future plans
Not sure where this will be when the talk happens…
Goal is to leverage Oomph to:
Download artifacts from P2 repositories
Setup targetplatform and projects for the developer
We’ll see how much is done in time for the talk