Target Platform Provisioning

Target Platform Provisioning

I’ve been doing bundle development for a very long time so I have a lot of fantasies of how we can improve development workflows. One of my fantasies while working with my target platform has been to have it automatically provisioned to me based on some requirements. Well, I’m happy to report that PDE now supports provisioning your target platform from a repository (as of Eclipse 3.5 M7) which makes my fantasty come true!

What does this mean? Well, let me walk you through a short demo:

The first thing to do is to create a new target definition in PDE (File->New->Target Definition):

target1

For the purposes of this demo, let’s create a empty target to work with the Eclipse Communications Framework (ECF):

target2

Next, let’s add some content to our target definition and choose the ‘Software Site’ source:

target3

Let’s point to the Galileo repository as that’s where the ECF SDK lives:

target4

Once that happens and we set our target platform, PDE will resolve the target definition and download everything that is needed:

target5

Tada! After waiting for the target to resolve and download, we have everything we need to develop against ECF!

What exactly is going under the covers here? Well, PDE now allows you to craft a target definition using p2 IUs from a software site (repository). Just as we selected ECF, we could be building another product that needs Riena and ECF so we simply select the Riena and ECF IUs. All software-site based target definitions now are managed by a p2 profile and share a local bundle pool in the PDE metadata area. These target definitions are now easily shareable with your colleagues. You simply have to craft a target definition with the right information and put it somewhere your colleagues can access it. One of the coolest things about this feature is that since we use p2, you can plug in any repository and things would work transparently. For example, if someone wrote a p2 connector to talk to Maven or OBR repositories, things would work transparently since everything is an IU!

Note that if you aren’t comfortable with people provisioning a target from a software site, you can choose the other sources for content (directory, features, installation) and ship a target locally or in a SCM (this was how things worked before).

In the future, you’ll continue to see closer PDE and p2 integration.

Hope this helps! If you have any bugs or suggestions, please file a bug.

15 Comments
  • Posted at 4:47 pm, April 29, 2009

    This is so nice, it almost brings tears to my eyes Chris. :)… Thank you…

    Kind of a strange fantasy, as fantasies go, but a strangeness that I share.

  • Posted at 7:36 pm, April 29, 2009

    Geez, I’ve been dreaming about this feat for a while ! Thanx so much 🙂

  • Posted at 7:36 pm, April 29, 2009

    What would be very useful to see is the ability to save the target definition file somewhere, so other developer could just take it and run without having to go trough the new wizard and selecting update sites and components that need to be provisioned.

  • Posted at 9:01 pm, April 29, 2009

    Chris, last time I looked at the target definition it had list of the local folders, so wasn’t really helpful outside local environment. Has that been changed? Can you maybe update your blog with an example of such file?

  • Posted at 11:10 pm, April 29, 2009

    Chris,
    so many good news – its like birthday and chrismas together 🙂
    …using 3.5 my cycles using 3rd party are history,
    target platform definition is so much easier in M6 and now M7 will push it into new dimensions.

    Eugene,
    if you’re working using local folders this can also be transportable. I do it this way:
    in my target definition files all local folders are using a string variable
    {targetRootFolder}/equinoxsdk/plugins and so on
    eclipse preferences – string substitution resolves
    string variable targetRootFolder=MyDisk/dev/targetplatform or so
    such a target definition file you can share easy – doesnt matter where the target-root folder is located,
    each developer only has to set the stringvar in his preferences
    I’m using this technic since 3.4 –
    now its much easier (3.5M6) because you have opne place for targetplatform, target definition files…

    after updating to M7 I’ll try a combination of software update sites and local folders (used for non-eclipse non-p2-aware bundles like EasyBeans EJB3 OSGI) – curious what will happen

    ekke

  • Posted at 12:18 am, April 30, 2009

    Chris, it may make more sense if you can show me the source text of the created target definition file. Thnx.

  • Posted at 12:20 am, April 30, 2009

    Ekke, my project have dependencies on 5 or more other projects that are outside of Eclipse Platform and some of them are outside of Eclipse. Assembling such target platform is a major pain and manual error prone work, so having a target definition pointing to the local folders doesn’t help much.

  • Posted at 5:38 pm, May 1, 2009

    One of the main things I am looking forward to in 3.5! thanks PDE team

  • Posted at 11:05 am, May 22, 2009

    Chris,

    This is awesome! Say, is there a way to update the target like it is possible to update the host installation via p2? I wondered why there are fixed versions (even with qualifiers!) in the target definition…

    Cheers
    /Eike

  • Posted at 5:29 pm, August 12, 2009

    Chris,

    How would this work with headless pde builds ? Would I need to update the “pluginPath” variable in the build.properties somehow to include software sites?

    Thanks,
    Eric