Home > Eclipse, p2, Target Platform > Provisioning your Target Platform as local p2 site

Provisioning your Target Platform as local p2 site

Provisioning your target platform from a p2/update site is a gem of a feature that was released with Eclipse 3.5. Chris called it “fantasy come true!” and so did many others. You could read the details on how this works from this article by Chris. (On the other hand, if you haven’t used target platforms at all, stop doing any further eclipse plugin development and read about it here first, right from the target platform expert Ekke).


Provisioning your target platform from a p2 site allows you to basically download any eclipse flavor you like, and with the click of a button set up your target platform. PDE downloads all the plugins required for your target platform automatically from different software sites based on your target definition and builds your workspace. Although this is a great feature, using this in your workflow has some shortcomings.

  1. If your target platform is large (which is mostly the case), this would end up in a lot of bandwidth usage every time the bundles are downloaded from different software sites. Also, if you do not have high speed internet or you have restricted internet access, the time to initialize the target platform could be very long.
  2. Not all bundles are available from p2/update sites. Although p2 marketing has been quite successful recently, many plugin providers still doesn’t host their products as p2/update sites. Although, you could have such plugins as local folders or in a shared network folder, this takes away the power of provisioning.
  3. Many p2/update sites don’t believe in archiving older versions and continue providing them as p2/update sites. Hence you have no guarantee that your platforms based on some older bundles will work forever.
  4. Many development projects version their target platforms and maintains them in versioning systems like SVN. This is a prerequisite to reconstruct older target platforms. This, however, is not possible with the approach above.

If you have a closer look, you could see that many of the limitations above stems from the fact that the software sites referenced are not local, nor within your control. All of them could be avoided if you provision your target platform as a local p2/update site. This means, instead of you downloading bundles from a public software site, you (and your team) downloads them from a local p2/update site that you have set up with all your required target platform plugins/features. In this article, I describe a workflow in setting up such a local p2/update site for your target platform.

1. The aggregation task

The first step would be to aggregate all the plugins and features required by your target platform. You could easily do this by creating a target definition file which references the software site of your bundle providers using “New -> Target Definition“. If your bundle provider doesn’t have an p2/update site, reference them from a local download folder.

You will never share/distribute this “setup” target file

A sample target definition file could look like this.

If you want your target to support multiple platforms, make sure to check this checkbox while you add a software site.

2. Testing the target

Using the target definition editor, set the target by clicking “Set as Target Platform“.

Additionally, you could set the target platform in “Preferences -> Plug-in Development -> Target Platform” and selecting the newly created target. If all the projects in your workspace builds fine, then you have setup the target platform correctly. Else repeat Step 1 to add the missing plugins and the workspace errors vanish.

3. Creating a new target platform feature

Using the feature project wizard, create a new feature for the target platform.

Make sure to properly name and version the feature.

In the plugin selection page, the plugins listed are the ones in your target platform together with your workspace plugin projects. Select all plugins except the ones in your workspace.

4. Creating a p2 site for target platform

You could do this either using PDE or using Buckminster.

If you want your target platform to support multiple development platforms (OSX, Linux, Windows etc.) use Buckminster (unfortunately, PDE had some export issues doing this)

4.1. Creating p2 update site using PDE

Create a new update site project using the update site project wizard.

Create a proper category and add the target platform feature you created earlier as child, using “Add Feature…“.

Build the update site using “Build/Build All“.

If the build is successful, the update site project could look like this.

4.2 Creating p2 site using Buckminster

Install Buckminster from update site http://download.eclipse.org/tools/buckminster/updates-3.6 (for Helios).

Create a buckminster.properties file in your target platform feature project.

## buckminster.properties ##

#Where all the output should go


# Where the temp files should go


# How .qualifier in versions should be replaced





Right click the target platform feature project and select “Buckminster -> Invoke Action…

Select buckminster.properties file created using “Workspace” button followed by “site.p2” from “Matching items” list

Select “OK” to close the dialog.

The p2 site would be created in feature folder pointed by buckminster.output.root in your buckminster.properties file.

You do not have to create a update site project (as you did in the PDE approach) while using Buckminster

5. Deploying the target platform

Identify a server space in your local network where the p2 site could be deployed (preferably a webserver). Copy the p2 site contents to this location.

6. Creating the final target definition

Create a new target file and point it to the newly hosted p2 site (similar to Step 1)

7. Testing the final target platform from local p2 site

Open the target file and set the target using “Set as Target Platform” as before. The bundles from the local p2 site will now be downloaded and your workspace built again. If you have zero errors, you have succeeded in setting up a p2 update site for your target platform. Distribute the final target file to your development team and they could now set their target platform in the same way.

8. Managing different versions of target platforms

You could provision multiple versions of target platforms at the same local p2 site. All you need to do is to create a new feature for the new target platform, add it to the update site site.xml, build and deploy the target platform as before and distribute the updated target file.

  1. SeB.fr
    October 11, 2010 at 11:20 am

    Great post, I’ll try it right now.
    One thing I’l like to know is the location of the plug-ins and features retrieved during the resolution when creating the intial target platform during your so called “aggregation task” ?
    Any idea ?
    thanks anyway.


    • October 11, 2010 at 2:05 pm

      Thanks for your comment.
      You could find the plugins and features under {your workspace}/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/ folder.

  2. SeB.fr
    October 11, 2010 at 4:33 pm

    thanks a lot for your answer,
    this lead me to another question and worry.
    In the final step of creating the “final” target definition” upon the newly created update site, do all the bundle go also into the workspace ?
    Because this is problem if you play around with multiple workspaces, you may have to update all your workspace every time your update site changes.
    And even though it does not change, you’ll end-up with a huge copy of all the site plug-ins as many times as workspaces.

    • October 11, 2010 at 8:26 pm

      Good question. But this is how target provisioner works in general. Whenever you reference a p2 site (local or public), TP copies the target to the workspace metadata folder. There is even a discussion on making TP project specific.
      At the moment, I don’t see a way to share the bundle pool across workspaces. The dirty way would be to do a “Export -> Target Definition” to export all the plugins/features in your current target into a “custom bundle pool folder” and reference them from difference workspaces.

  3. Curtis
    • October 12, 2010 at 6:02 pm

      Thanks for the links Curtis. Very useful.

  4. Jan
    February 7, 2011 at 11:40 am

    Hi Nirmal, nice tutorial.
    But I’ve a problem with generating p2.site using Buckminster. When I create a feature with selected all those plugins and features from my target platform (they should be packaged in this feature) and then I invoke bucminster’s p2.site action on this feature, the site is generated well but Help – Install New Software in my IDE says “there are no items available” in that p2.site.

    • February 7, 2011 at 3:20 pm

      Hi Jan,

      Can you check if content.jar/artifacts.jar is generated when you invoke p2.site action? Also when you installed from the p2 site, did you try unchecking “Group by Category” (incase you have no category)?

      • Jan
        February 7, 2011 at 4:01 pm

        Yes, content.jar and artifacts.jar are generated (whole p2.site is about 300MB large). And yes, I tried unchecking “Group by Category”.

        I found the solution. I need to create another feature. This feature only includes the “target feature” which itself contains all plugins from the target platform. This way it works fine.

        But I would like to know if this is only a workaround or if I did something wrong before.

  5. February 7, 2011 at 4:04 pm

    Hi Jan,
    This is indeed the right way to do it with Buckminster. I somehow missed it in my tutorial. Thanks for pointing this out. I will update my tutorial accordingly.

  6. Kap
    October 19, 2012 at 12:24 am

    Hello guys, I tried to build a p2 site using this tutorial, but my artifact.xml is not there. I am probably missing something. I think it is missing the “publish” of artifacts, as I can see my features (the content of every folder is jar/ and temp/).

  7. November 3, 2012 at 7:51 pm

    Have you tried with Juno (RCP SDK 4.2)? Trying to build the site.p2 with Buckminster reports

    No component named org.apache.ant:osgi.bundle/[1.7.0,2.0.0) is known to Buckminster

    and I think also other dependencies will be missed…

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: