Use Target Definition Files in PDE Build

I’m not hip when it comes to building Eclipse based products. I still use plain vanilla PDE Build. The cool guys all switched to Tycho. Well, you’re allowed to call me dinosaur then. Anyway, I’ve been using .target files as a source for dependency management for quite a while now. They are very useful in Eclipse. All dependencies for all the bundles are defined in one place. You simply open one and Eclipse starts downloading one half of the Internet. Maven already did the other half, I’ve heard.

I also use them to drive PDE Build. Instead of specifying stuff to fetch for a build again I simply point PDE Build to the same .target file I use in the IDE. Works like a charm as long as you only use “Software Sites” (p2 repositories) which are accessible via URL by any developers Eclipse instance as well as the build machine.

Previously, this was implemented by transforming the .target file XML using XSL into an Ant script. The Ant script did a bunch of p2 mirror calls to download the bytes. I recently upgrade to a newer version of the builder containing a Juno version of the org.eclipse.pde.core bundle. Starting with 3.8 this bundle defines a nice Ant task that does not require the XSLT magic.

<target name="buildTargetPlatform" unless="skipTargetDefinition">
  <!-- note: this requires pde.core (from Juno) in the base builder -->

5 thoughts on “Use Target Definition Files in PDE Build

  1. Thanks for sharing. I didn’t know it was possible to use the .target file directly. Was the XSL file you mentioned part of PDE build or did you write it yourself?

  2. Hi, does this Ant task still works with Eclipse SDK 4.12? I tried it similar to your example but Ant is unable to find the task definition for pde.provisionTargetDefinition. Did I miss some configuration that I need to do? Also I would like to verify if this is applicable also for PDE headless builds.

  3. There is a caveat with this task: When including a fragment with MANIFEST.MF Eclipse-BundleShape: dir the task will export it as directory instead of a jar. So when using this exported target via maven, results like

    Artifact osgi.bundle,org.eclipse.equinox.launcher.gtk.linux.x86_64,1.2.100.v20210209-1541 is a folder but the repository is an archive or remote location.

    may appear. It seems like there should be an option like “ignoreBundleShape” to keep the resp. files as jars not unpacking them.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.