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 300x187 Target Platform Provisioning

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

target2 239x300 Target Platform Provisioning

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

target3 300x243 Target Platform Provisioning

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

target4 290x300 Target Platform Provisioning

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

target5 300x188 Target Platform Provisioning

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.

You may also like...

Share this Post

Twitter0
Google+0
LinkedIn
Facebook

Tags

15 Responses to “Target Platform Provisioning”

  1. 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.

  2. Thank the PDE team! We worked hard to update the target platform story for the Eclipse 3.5 release!

    I can’t wait to see what the future holds!

  3. Geez, I’ve been dreaming about this feat for a while ! Thanx so much :)

  4. 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.

  5. Eugene, you can do this! :)

    Target definitions can be saved in a project and shared with colleagues. PDE automatically picks them up if the target is in your workspace. You can also ship target definitions inside a plug-in using the org.eclipse.pde.core.target extension point.

  6. 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?

  7. Eugene, that’s one option of working with a target which works for some people who like to store things in an SCM. For example, I know people that store their target in a SCM along with a target definition that points to those bundles. This allows people to effectively manage their target inside an SCM. In the example above, the target definition that I created only contains the repository and the IUs you want from their as your target platform. I could take that target definition and easily send it to a colleague or ship it in a plug-in and have my colleague simply resolve the target… everything would work.

    Does that make sense a bit more?

  8. ekke says:

    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

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

  10. 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.

  11. John Conlon says:

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

  12. Ekke, it’s important when you use a combination of software site and directory bundle containers that you understand what’s going on under the covers. For example, everything provisioned via the software site bundle container is managed by a p2 profile. This means things like the delta pack can’t be provisioned via the software site mechanism since everything in your profile targets a specific os/arch… So to add the delta pack and other native things that aren’t for your specific host os/arch, you need to use the other mechanisms to add it to your target.

    In the future, we look to work with the p2 team to expand what we can do with it.

    Hope you like it!

  13. Eike Stepper says:

    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

  14. Eric Geordi says:

    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

  15. Eric, you want to pay attention to this enhancement request in PDE Build.

15 responses so far

Written by . Published in Categories: Planet Eclipse