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 :)

13 Responses to “Target Platform Changes”

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

  2. ekke says:

    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

  3. Eric Rizzo says:

    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.

  4. zx says:

    The Eclipse community is so demanding :)

    @Patrick, right now, we haven’t written anything to materialize a target from a Maven repository. I could imagine you hooking into p2 and have p2 become Maven aware… because essentially they are similar technologies… and even using the same SAT resolving technology under the covers. I believe these things will come with time.

    @ekke, I would wait until 3.5M6 :)

    @Eric, I give you an inch and you want a mile :)? PDE Build isn’t aware of these files at the moment.

  5. ekke says:

    thanks for the hint ;-)

  6. Phil Quitslund says:

    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!

  7. Phil, the issue I was referring to is the problem of the “singleton” target platform. Right now, you can only point to one target and have that apply to the workspace. You can’t have a target per project. Imagine you’re developing an application that runs on RCP and RAP. That’s two targets you’re working with… currently you have to switch workspaces depending what you’re targeting. Now imagine if you can just say that these set of projects target RAP, these target RCP. The bug open for this issue is:

    159072: [target] associate target definitions on a per-project basis (multiple target platforms per workspace)

    In your use case, if you grab tomorrow’s i-build (3/3/09), I would look at doing this:

    1) Create your target definition using the new wizard
    2) You can have people create a new target definition as a template and use that from the wizard
    3) Success?

    I think there are many ways to achieve what you want but that may be the simplest way at the moment.

    Keep the requirements coming though, it helps us flesh out the story better!

  8. Phil Quitslund says:

    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.

  9. Phil Quitslund says:

    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?

  10. So once you have the created, you can instruct your users to create another target definition… one of the options when creating another target definition is to use another one as a “template.” You could pick your existing target definition as a template and people can go from there and add what they need to their newly minted target definition.

    Another way that people are starting to craft targets is using the repository target provisioner… for example, say you already have your bits located on some repository and you want people to add it to their target. When people create a new target definition and go to add plug-ins, there should be a “Repository” option which will allow them to point to your repository and grab your bits to add to their target. That’s one way to do it.

    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.

  11. Phil Quitslund says:

    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!

  12. So, we do have some thoughts about composing target definitions but haven’t fleshed the idea out further:

    264911: [target] composable target definitions

    The problem mainly lies that you can achieve similar functionality with features… as what you’re really looking for is a way group bundles and reference that grouping. Please let us know how things turn out… you’re literally living on the bleeding edge!

  13. Phil Quitslund says:

    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.

13 responses so far

Written by . Published in Categories: Planet Eclipse

Looking for a job?

Karlsruhe / Remote
Karlsruhe / Victoria / Remote
Karlsruhe / Victoria / Remote