Gradle and Eclipse RCP Ned Twigg All code

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 Team. City / Artifactory / Git. Blit 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 Diff. Plug, 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 incrementalupdate) 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 autoupdater are all uploaded and live.

What’s missing in Gradle core (we’ll address each in turn with either a plugin or a workaround) 1. Consume dependencies from P 2 • Gradle can speak Ivy, Maven, and flatdir, but not P 2 2. Generate OSGi metadata • Lots of ways to generate OSGi metadata, with varying levels of automagic • Difficult to sync MANIFEST. MF with Eclipse 3. Setup a targetplatform • Need to ensure Eclipse and Gradle are working from the same stuff 4. 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 P 2 • Nobody is working on native support at the moment • stalled gradle-dev discussion about adding support for P 2 • https: //groups. google. com/forum/#!searchin/gradle-dev/p 2/gradle-dev/YQ 2 V-Riz. Qg/sw. XSWe. Gmqbo. J • 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 Git. Hub • 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 1. Create a ‘targetplatform’ project, and apply bnd-platform to it. 2. Declare all of your plugins as a dependency of targetplatform 3. 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 • Pde. Product. Build. Task • Pde. Ant. Build. Task • P 2 Director. Model

Goomph – future plans • Not sure where this will be when the talk happens… • https: //mail. google. com/mail/u/1/#search/goomph/150 f 51 f 6 ac 32 f 988 • https: //www. eclipse. org/forums/index. php/m/1714355/? srch=goomph#msg_1714355 • Goal is to leverage Oomph to: • Download artifacts from P 2 repositories • Setup targetplatform and projects for the developer • We’ll see how much is done in time for the talk