Target Platform Changes

Target Platform Changes

I sent an email out to eclipse-dev today detailing some of the changes the PDE team has made to the target platform story:


Dear Eclipse Plug-in Developers,

In 3.5M5, the PDE team added a new experimental preference page supporting managing and editing of multiple target platforms: Plug-in Development > Target Platform (Experimental). In the latest i-build (20090224-0800), this page has become the default way of managing target platforms and the old page was removed. The page displays all targets defined in the workspace. You can change the target platform used to build workspace plug-ins by checking it in the table. A wizard allows you to add and edit target platform definitions. You can seed a target platform from existing templates (for example, an RCP application), default settings, current target platform settings or start from scratch. Target definitions created from the preference page, by default, are stored locally in your workspace metadata. You can add plug-ins to a target definition from various sources: a directory, an installation (this looks at the list of INSTALLED bundles), a feature, or a repository (update site). You can also scope which plug-ins or features make up a target definition. Also, you can create a target definition from the New -> File -> Plug-in Development -> Target Definition wizard and share it with your friends (use variables if you want a target definition to be shareable).

Please note that this is a change to how people worked with target platforms before. In the past, you just pointed to a directory and magic happened. This was a very brittle way of working with targets and wasn’t conducive to sharing with teammates. In the future, look for PDE to support target platform materialization from p2 repositories and the much requested feature of multiple targets per workspace.

If you find any issues with the new target platform story, issues with the new target workflow or have suggestions, please file a bug against PDE with a starting summary of “[target] xxx”

This is really exciting stuff as your target platform can be crafted now and easily shared with teammates. We are also looking at supporting target platform materialization from places like p2 repositories… OBR and other places where bundles may be stored. In the end, the PDE team hopes that you’ll enjoying crafting your target platforms in the near future 🙂

  • Posted at 00:49, 2009-02-25

    That’s indeed very exciting – platform materialization is just so hard right now, especially for RCP development.
    p2 repositories and OBR are a good start, what about maven repositories?
    Spring source is currently publishing a lot of bundle in their maven repository @
    And with the new maven tycho plug-in (from the m2eclipse project) you can now publish your own plug-ins to your local repository.

  • Posted at 08:36, 2009-02-25

    this sounds like a dream 😉
    …will make it much easier then before, where I defined TargetPlatform Definition files and loaded this file –
    now – as I understand it right – I have ONE place to select or define my definitions.
    great !
    …hopefully next week I can switch my development from 3.4.1 to 3.5.M5 and then a new life begins without cycles etc

  • Eric Rizzo
    Posted at 15:14, 2009-02-25

    What, if any, is the coordination of this feature with PDE Build? If we can’t use the same target definitions in a headless build as we do in the IDE, we’ve still got major problems.

  • Posted at 21:04, 2009-02-25

    thanks for the hint 😉

  • Phil Quitslund
    Posted at 23:56, 2009-03-02

    When you say: “the much requested feature of multiple targets per workspace,” is there an open bug for this? I’ve been poking around but haven’t found one to check out. I *think* this feature is what we’re looking for but maybe you can set me straight. 😉 In case if you want to try, here’s a bit of context:

    We’d like to contribute a new target (via the org.eclipse.pde.core.targets extension point) that contains a number of library classes. This is essentially a “Library” target that aggregates a bunch of libraries the user needs to have available to do product work. The idea is that a user should select RCP Base *and*, optionally, also add our target to get our contributed libraries. The question is whether supporting this story is on the roadmap and/or whether there’s another suggested way to solve the problem.

    Thanks in advance for any thoughts or pointers!

  • Phil Quitslund
    Posted at 00:34, 2009-03-03

    Hey Chris,

    Thanks for the follow-up and thanks for setting me straight on the singleton issue (pain I’ve felt too!) I’ll grab an i-build tomorrow, play with it and post impressions.

  • Phil Quitslund
    Posted at 19:26, 2009-03-03

    Hey Chris,

    I grabbed the latest i-build and have been playing around but am not quite sure I follow your suggestion. Here’s the example I tried to work through. For the purposes of this exercise suppose my team is trying to help RCP developers add CVS support to their RCP projects.

    1. I create a new target defintion “” that includes the “org.eclipse.cvs” feature
    2. I contribute it using the “org.eclipse.pde.core.targets” extension point
    3. I launch a runtime workbench
    4. I go to set the target platform and see my new CVS target definition as a template

    The problem now is that if I select this target as a template the ONLY features my platform includes are the CVS bits. What I really want is a way to add the CVS bits to another set of targets. That is, I want to say “give me the RCP bits, the CVS bits, the JUnit bits, etc…”

    Does this make sense? Maybe there’s a better way to do this? Popping up, when you get folks set up doing RCP development, how do you help them get their targets setup if they need more than just the base RCP bits?

  • Phil Quitslund
    Posted at 20:33, 2009-03-03

    Thanks for the reply.

    This bit hits the nail on the head:

    “The mindset now is that RCP developers craft their own targets. If they need more functionality, they can modify their target and add a set of plugins from a directory, feature, installation or repository.”

    The key is that the units of target content definition are directories, features, installations and repositories and NOT other targets like I was imagining. The picture I had in mind was of composite targets but now that I see that that is not a design goal I see better where things are going.

    For my use case, adding a feature is probably the most straight-forward way to go. Since the target content I’m describing is really secondary, it feels strange to use it as a jumping off point as a template and require a user to add everything else.

    Thanks for your help sorting this out!

  • Phil Quitslund
    Posted at 00:13, 2009-03-04

    Aha. Thanks for the pointer to that bug (I really should have seen it!) I’ll kick things around a bit more and post thoughts later. An maybe we can pick up the conversation over beer at EclipseCon? In the meantime, thanks again for all your following-up.