Gradle and Eclipse RCP Ned Twigg All code examples available here https://github.com/diffplug/gradle_and_eclipse_rcp

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

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.

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

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.

1. Consume dependencies from P2 Nobody is working on native support at the moment stalled gradle-dev discussion about adding support for P2 https://groups.google.com/forum/#!searchin/gradle-dev/p2/gradle-dev/YQ2- 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

2. Generate OSGi metadata Gradle ships with an OSGi-generator, and there are several on GitHub All have bugs, except https://github.com/jruyi/osgibnd-gradle-plugin 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

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

4. Run Eclipse PDE headless PdeProductBuildTask PdeAntBuildTask P2DirectorModel

Goomph – future plans Not sure where this will be when the talk happens… https://mail.google.com/mail/u/1/#search/goomph/150f51f6ac32f988 https://www.eclipse.org/forums/index.php/m/1714355/?srch=goomph#msg_1714355 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