RCP Target Platform Tips

Setting up a target platform for an Eclipse Rich Client Platform application is fairly simple. You simply download the RCP SDK, extract it to a directory, and then use the Target platform preferences page to point to the new directory. But managing target platforms over time can be more complicated, and I’d like to pass along a few tips I’ve learned the hard way.

Maintain a separate target platform for each application.

The plug-ins that make up a target platform are as much a part of your application as the code you write, and this set of plug-ins will vary from one application to the next. One application might require the forms API. Another might use cheat sheets. Creating individual target platforms for each applications allows you to more easily manage these dependencies.

Make it easy for developers to create or link to target platforms.

Developers come and go on most projects and the first thing a new developer will need to do is set up a target platform. One way of making this easier is to create a wiki page listing the plug-ins that make up a target platform. Even better, just keep your target platform on a shared drive so everyone on the team can access it.

Version your target platforms.

Wiki pages and shared folders are great, but if you want to go all the way, consider versioning your target platforms along with your application source code. This makes it even easier to support new developers, and also makes it much easier to rebuild previous versions of your application.

Adding a new plug-in to your target platform is a big deal.

Adding a plug-in should be an explicit decision driven by your application’s requirements. When using the default target platform (Eclipse itself), it’s much too easy for developers to simply add dependencies on whatever plug-ins they like. Adding a new plug-in will generally require changes to your feature definitions, launch configurations, production configurations and automated build processes. Make sure the decision to add a plug-in to your application gets the deliberation it deserves.

A little work up front goes a long way.

Having said all that, I don’t want to make dealing with target platforms sound like rocket science. It’s usually a fairly simple aspect of RCP application development, as long as you treat it with the respect it deserves. The teams I see suffering from complications are those that never specifically address the issues posed by target platforms. With a little effort up front you can save yourself from some serious headaches.

Advertisements

20 Responses to RCP Target Platform Tips

  1. Are you creating target definition files and managing these in some repository?

  2. Patrick says:

    Hi Chris,

    No, I’m not currently working with target definition files. I just version the target platform itself as disk space is cheap and the targets don’t change that often. I’ve always been curious about target definitions, but it seems like I’d have to manually construct the actual target during an automated build.

    I’d be curious to hear what your thoughts are on how to best manage target platforms, and especially how target definitions can best be used.

    — Patrick

  3. Carlus Henry says:

    Patrick,

    Nice followup.

    Is there a way to set up the target platform on a project-by-project basis? Let’s say that I am working on a plugin application that I want to be very light weight. I setup a very minimal target platform through the Window -> Preferences. However, this will change the target platform for my whole eclipse environment, as well as other plugin projects that I may have open and I am actively working on.

    By being able to set the target platform on a project by project basis, this will alleviate a lot of errors that I am receiving now, due to the missing plugins that are required by my other open projects.

    Thanks

  4. Patrick says:

    Hi Carlus,

    No, the target platform is not a project scope preference. But then again, an application will usually be made up of many plug-ins/projects, so that makes sense.

    I usually try to have a single workspace per application, much like I have a single target platform. It’s not a bad thing to have many workspaces and target platforms, as long as you manage them well.

    But if you really need to have multiple applications in the workspace, you’ll need to create a target platform that represents the superset of all plug-ins required by the applications. Or you’ll need to suffer the compile errors.

    — Patrick

  5. Nice post Patrick.

    Apparently target definition files are the cool in way 🙂 You might find this bug thread interesting:

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=186618

    Cheers,
    Kevin McGuire

  6. Ed MacKerrow says:

    Great helpful discussion Patrick,

    I am curious as to your suggestions for a code team using CVS. Would you have the workspace associated with the application under team development also shared in the repository. I am assuming that for each new application you (1) download a new SDK set of plugins to a folder (is this inside your workspace? – no?), and then (2) create a new workspace specific to the new application?

    I have been using one workspace for many, many, different RCP application developments. Now I think I see why I have all kinds of runtime weirdness — by not having a separate workspace for each application.

    Thanks

    Ed

  7. Patrick says:

    Hi Ed,

    Good to hear from you! Sorry for the delay in responding, but I’m just getting back from a much needed vacation.

    To answer your question, yes I prefer to have a separate workspace for each application I’m working on and I have a corresponding target platform set up for each one. I download the SDK for each target and place these in directories outside of the workspace. My actual “work” folder looks like this:

    Workspaces
    —> App 1
    —> App 2

    Targets
    —> App 1/eclipse
    —> App 2/eclipse

    Hope this helps,

    — Patrick

  8. Ed MacKerrow says:

    Hi Patrick,

    Thanks Patrick, that make good sense on how to set up things. Hope you had a great vacation, thanks for the fast response.

    I will set up things accordingly… now I know why I had so much trouble having to rebuild run configurations — I was using the same target, and workspace, for 100 or so different Eclipse projects (ouch). 🙂

    Cheers,

    Ed

  9. Alex says:

    Hi Patrick,

    After reading your post, and struggling with my own RCP dependency management issues, I put together an Ant Task and tutorial to help.

    As I’m pretty new a this I wasn’t sure if I was re-inventing the wheel, so would be interested on yours and anyone else feedback. You can find it on my blog here: http://ezaero.blogspot.com/2008/08/bushel-making-osgi-bundle-mamangement.html

    Cheers,
    Alex

  10. Millard Ellingsworth says:

    I noticed that the eclipse.exe that gets dropped down when unzipping the RCP SDK to create the target platform isn’t runnable (which may be as it should be). So how do you get the scads of NL fragments added to the target? My first thought was to run the target, connect to Babel and let it deal with it, but since the target doesn’t run…

    Or did I just miss something? Great blog by the way, thanks for taking the time to share.

  11. Patrick says:

    Hi Millard,

    Yes, your target platform will not be a runnable instance of Eclipse and cannot be constructed using the standard update mechanisms. The eclipse.exe is exactly the same as the one used for a regular Eclipse install, but the mix of plug-ins in the RCP SDK is not sufficient to run the IDE.

    I would suggest simply extracting the NL fragments into the target platform. If there’s some reason this isn’t practical, I’d be happy to help work through the issue.

    — Patrick

  12. Millard Ellingsworth says:

    Thanks for the reply. I guess it depends on your definition of practical. It’s mostly a one-time issue (you could re-use a Target “template” once you had created one), but just about every plug-in has a collection of a dozen or so localized fragments, so the opportunity to goof and miss a couple certainly exists. And it can be even messier if you add plug-ins to the target and/or want to add languages to the target later. A runnable target (and I appreciate why it isn’t, out of the box) would alleviate much of that through use of the Eclipse update mechanism.

    I’ve done this by hand to add Spanish to the product and I focused on plug-ins that were likely to have UI visible components (and it seems fine), but I didn’t copy the NL fragments for every plugin in the target (and I realize I probably should) and because it is a very manual process, my temptation is to copy in all of the NL fragments whether I need them or not just so I won’t have to go through it again — but that seems wasteful. I’m still a bit of a noob and was just hoping there was a better answer.

  13. Patrick says:

    Hi Millard,

    I understand how you feel about the messiness of setting up a target platform. My approach has been to be extremely meticulous about my target platforms. Nothing goes in unless it’s absolutely necessary and things are removed as soon as some dependency is no longer needed.

    In your case, I would only move the fragments into the target platform when their hosts are in the platform as well, and I would only add the fragments for the languages you care about. Once you’ve set up an initial target platform, you can use some of the suggestions in the post above to manage the platform over time.

    One suggestion I would make is to consider placing the NL fragments in a separate feature. This would allow you to build and distribute your app with or without the fragments as needed.

    — Patrick

  14. Millard Ellingsworth says:

    I can probably work that out. So would you recommend a feature-per-language or language group? Slobovian may not make the first round — better to update the NL feature with it later or add a feature when it is ready?

    BTW, I thought of a really good reason to follow your advice on this — If the Eclipse fragments somehow got shipped with the primary feature, the application would look partially localized with all the Eclipse stuff looking fine and my stuff looking very English. I appreciate the dialog and your time.

  15. Patrick says:

    Hi MIllard,

    I would map your features to whatever distribution plans you have. If you’d like to ship languages as a pack, create the feature that way. If you’d like to ship individual languages, then package each as a feature.

    — Patrick

  16. Millard Ellingsworth says:

    How does a feature play in the Target platform? If I have an optional Feature for the language pack, does it appear in the features subdir of the target? Do I need to represent it there somehow? What about the scads of *.nl_*.jar files I now have? Just toss them all into the plugins subdir or is there a way to segregate them? Thanks again (and again).

  17. Patrick says:

    Hi MIllard,

    First, features that you create will be in your workspace. If there are other features you would like to include (EMF, GEF, or whatever), those features should be placed in your target platform. The same is true for optional features.

    As for segregating different parts of your target platform, you can use Target Definition files to achieve this. Check out the following help topic for more info:

    http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tools/file_wizards/new_target_definition.htm

    — Patrick

  18. Millard Ellingsworth says:

    While I have your attention, is there a straightforward way to determine which of the plugins that may be in your target (say, even from the “standard” collection) that you really don’t need and should remove or disable?

  19. Patrick says:

    In your launch configuration you can uncheck all the target platform plug-ins and then click Add Required. Only the ones used will be checked and you can remove the rest.

    — Patrick

  20. Build Automation for your Target Platform…

    The target platform is an important concept for delivering a well defined product. It should always be a deliberate and dedicated step to change it. The article RCP Target Platform Tips points out some important rules to which I fully agree. I would f…

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: