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 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 P2
• Gradle can speak Ivy, Maven, and flatdir, but not P2
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 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/YQ2V-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
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
• 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