Recently I had the pleasure of updating the way Yoxos is built.  Like a lot of Eclipse based applications, the Yoxos build was feature based and we naturally use the normal headless PDE/Build scripts to do this.  To make things a little easier to extend, I decide to use the new product based builds (new is relative, as product builds have been around since about Eclipse 3.2).

There are a number of subtle points that I think are worth mentioning.

1. PDE/Build does not checkout the .product file

As you may know, when you specify a product build, you use the following build.property setting:

product=/some_bundle_or_featre/your.product

However, PDE/Build does not fetch that bundle or feature from your SCM system (See Bug: bug 159128)

To get around this problem, you can use a post setup custom target like this:

 <ant antfile="${genericTargets}" target="fetchElement">
    <property name="type" value="feature">
    <property name="id" value="org.feature.containing.product.file">
 </ant>

2. Platform specific products require platform filters

When I converted to product builds, I decided to build platform specific products (with platform launchers, etc…).  If any of your features contain platform specific fragments, make sure you set the conditions under which the fragment can be installed.

If you don’t set these, and the bundle or fragment has set platform filters, then at build time the fragment won’t be included, however, the feature will still require it.

3. Make sure your delta pack matches your platform

If you are building a product that targets a number of different architectures, then you are likely familiar with the delta pack.  It’s very important that you use the delta pack that matches your platform version (i.e. don’t use the Eclipse 3.5.1 delta pack with Eclipse 3.5.0). At build time, the executable features (found in the delta pack) has a requirement on the org.eclipse.equinox.launcher bundle.  This bundle comes with the platform and the versions must match.

4. Make sure all your bundles are contained in a feature

If your product is feature based, make sure all the bundles that constitute your product are listed in a feature.  This is one of those errors that manifest itself as it worked when I ran it from Eclipse, why doesn’t it work on the build machine. The reason for this is you likely had all your bundles in your workspace when you launched from Eclipse, so PDE was able to track down these dependencies for you.  When you build on the server, only things that are explicitly included are fetched for building.

5. Check your javacSource setting

If you are using newer java constructs like generics (again, new is relative as these constructs have been around for over 4 years), make sure your java settings reflect this. However, changing your compiler settings in your workbench will have little effect on a server 1/2 a world away.  To influence the compiler settings during build, you can set the following properties in your build.properties file:

# Default value for the version of the source code.
# This value is used when compiling plug-ins that do not set the
# Bundle-RequiredExecutionEnvironment or set javacSource in build.properties
javacSource=1.5

# Default value for the version of the byte code targeted.
# This value is used when compiling plug-ins that do not set the
# Bundle-RequiredExecutionEnvironment or set javacTarget in build.properties.
javacTarget=1.5

Happy building!

Tags: pde build