I have prepared an example build setup that builds the RCP Mail Template and produces a p2-ized product. All the files needed for this are provided HERE.
The first step is to set up Eclipse with the RCP Delta pack which is required for the headless build of RCP products:
- Get the Eclipse SDK and the RCP Delta pack and unzip into the same location on disk.
- Start Eclipse and go to Window -> Preferences -> Plug-in Development -> Target Platform.
- Uncheck the option "Build target platform based on the target's installed plug-ins."
The p2 Installable Unit (IU) that will be created for this product will take its id and version from the product id and version set here. I am setting the version to end in "qualifier" so that I can replace the qualifier at build time with the build id.
The product configuration for this example is based on plug-ins. On the configuration tab remove all plug-ins, add the plug-ins listed below and click Add Required Plug-ins.
- com.acme.rcp
- org.eclipse.equinox.p2.exemplarysetup
- org.eclipse.equinox.p2.ui.sdk
- org.eclipse.equinox.p2.touchpoint.eclipse
- org.eclipse.equinox.p2.touchpoint.natives
- org.eclipse.ecf.filetransfer
- org.eclipse.ecf.provider.filetransfer
Setting up the headless build
I like to run the headless build from inside Eclipse using a launch configuration. To do this, first import (Import... -> Plug-in Development -> Plug-ins and Fragments) "org.eclipse.pde.build" from the target platform into your workspace as a binary project.Next, create a new general project named "Builder" and copy
org.eclipse.pde.build/templates/headless-build/build.properties"into the builder project.
/customTargets.xml"
I want my headless build to do 3 things differently from a normal build:
- Set the version number in the product file to match the build id.
- Generate p2 metadata
- Use the generated metadata to perform p2 installs to get the final archives
1: Set the version number in the product file.
See the Build/customTargets.xml/preSetup target. We copy the "acme.product" file out of the com.acme.rcp bundle and into our buildDirectory. We then use the ant replace task to replace the version qualifier based on the time stamp. This uses a "acmePlugin" property which we will define separately. We also save the time stamp to a properties file that we read later when calling the p2 director.2: Generate p2 metadata
PDE/Build provides integration with p2 to automatically generate p2 metadata. See Builder/build.properties where the following properties have been set:generate.p2.metadata = true
p2.metadata.repo=file:${buildDirectory}/repo
p2.artifact.repo=file:${buildDirectory}/repo
p2.flavor=tooling
p2.publish.artifacts=true
3: Perform p2 installs and archive the results
We do this in the Builder/customTargets.xml/postBuild target. We exec a new instance of eclipse to run the director application to install the product into a temporary directory and then we zip up the results.We are running the same eclipse install again to do this. This means that any repositories that the eclipse install is set up with will also be considered during the director call (in addition to the repositories we pass on the command line).
The rest: build.properties
There are a few other properties to set in the build.properties file. We also set a number of properties on the command line in the launch configuration.In the build.properties we set the product property to be the one that has the modified version qualifier. We also set the configuration we are building for.
product=${buildDirectory}/acme.product
configs=win32,win32,x86
On the command line we are setting:- pluginPath: allows us to not copy the com.acme.rcp plugin into the buildDirectory.
- buildDirectory: where all scripts will be generated and the location of our modified acme.product file.
- baseLocation: We use the eclipse install we are running as our base.
- acmePlugin: Define the location of the acme plugin for our custom task.
Results
Go to the Run Configurations... dialog and run the "Build Acme Product" launch config. The resulting zip should be under Builder/result. The project may need to be refreshed to see the results.Running the build multiple times will result in the repository containing multiple versions of the product. You can then use that repository to update the product from one version to the next.
Problems Encountered
I did encounter some problems while creating this example.- Bug 237662: The metadata generator currently does not properly handle the new p2 simpleconfigurator style of config.ini and loses some start level information. This causes the installed product to not start. Workaround for this example is to not include org.eclipse.equinox.simpleconfigurator in the product. I will provide another example later to work around this problem.
- Bug 222969: When including the org.eclipse.equinox.simpleconfigurator bundle in the product, the install is getting a bad relative path in the config.ini. Since we are excluding the simpleconfigurator because of the previous bug, this doesn't affect our example.
- Bug 237647: NullPointerException in the director. This only occured once, workaround was simply to remove the bad profile directory under my eclipse install (eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/ACMEProfile.profile)
