[Helios] Target Platform – how to deal with optional RAP dependencies

If you read about my problems about RAP in the IDE from last months, please cool down: this time I’m talking about RAP in the Target Platform as a first Helios review.

please remember:

  • the Eclipse IDE is the tool you’re working with to create powerful software (Plug-ins, products, …). the Eclipse IDE is based on SWT and you’re in trouble if RAP comes into the IDE. I’ll blog about solutions soon…
  • Target Platforms contain all bundles (Plug-ins) you need to compile against while developing your products. Target Platforms are also the base from where you get your Plug-ins used in Launch Configurations to run and test your products.
  • Target Platforms can be very different and if you’re looking at the Eclipse Runtime projects you’ll notice that this is a fast growing area. Two prominent examples of different Platforms are RCP(SWT) for desktop apps and RAP(RWT) for web apps –  and that’s what I’m talking about in this blog.

Hint: if you’re from germany, there was an article-series about “Eclipse Target Platforms” I’ve written for  “Eclipse Magazin” 2.2010 – 4.2010.

The last year while Helios was developed, RAP supports more and more projects, per ex. EMF and Riena. If you have dependencies on these projects, then you have to be aware that RAP can become part of your Target Platform by magic – even if you only develop RCP solutions.

Perhaps you ask why does this happen ? Projects supporting RCP and RAP are using ‘optional dependencies‘ to make this possible.

example: use Riena Target Components

Here’s an easy to reproduce example what can happen if you install Riena as Target Platform:

  • please download latest Helios SDK (this is RC3 as of today 2010-06-03)
  • create a project and in this project create a new Target Platform Definition file
  • add from Helios Software Site ‘Riena Core Target Components

perhaps you don’t know, but Riena needs also Plug-ins from Eclipse RCP SDK and Equinox Target Components which are not part of the SDK.

Save the Target Platform file and “set as Target Platform

Thanks to P2 and PDE: if you check  “include required software” you get all dependencies automatically :)

But: “include required software” also includes all optional dependencies and this means you also get RAP. Take a look at the plug-ins view:

Perhaps you’re thinking you can ignore the Plug-ins because you have no dependencies to RAP, but it isnt’ so easy. Take a look at plugins from RAP and RCP, per ex. …jface.databinding: …

…uuups – both are exporting exactly the same packages – so you never know which will be picked. (Exporting the same packages is one of the tricks to be able to single-source your RCP / RAP applications)

Fortunately there are some solutions how to deal with this:

Remove unwanted content from your Target Platform

Go back to your Target Platform Definition file, switch to tab “Content” and deselect what you don’t need:

Now there are no more RAP Plug-ins in your Target Platform and you can work as before using Galileo.

You can also define two different Target Platform definitions; one without RAP and the other one without RCP/SWT. Then you can easy switch and test your product for both platforms.

Exclude unwanted Plug-ins from your Launch Config

If you let all inside your Target Platform, then you have to be carefully while defining your Launch Configurations where you can select which Plug-ins should be used to run a product / application. Don’t mix RAP and RCP in one launch config or product !

If you have RCP and RAP plug-ins in your Target Platform and you want to be sure that a specific Plug-in project should compile against one specific platform, you can add these (classpath)dependencies to your Plug-in project without making your MANIFEST.MF dirty:

Open your MANIFEST.MF, goto Tab “Dependencies” and add those dependencies under “Automated Management of Dependencies“:

Now PDE will compile against org.eclipse.jface.databinding without the need to add this as a required bundle.

Curious where this is stored ? Take a look at the build.properties:

Don’t use “include required software”

There’s another option how to get rid of RAP Plug-ins while defining your Target Platform: don’t use the “include required software” checkbox:

Now you explicitely can configure what should be part of your Target Platform – but the drawback is: you’re loosing P2 comfort getting all dependencies automatically for you.

Adding all dependencies manually can be easy….

…or painful if you’re dealing with complex Target Platforms.

Hint: if you uncheck “Include required software” this will be for all locations defined for your Target Platform – not only for one site.

from my POV it would be great to have a second checkbox to fine-tune the dependencies: “Include optional dependencies” – see comment #8 on Bugzilla 315385.

Summary

Defining Helios Target Platforms you maybe have to live with RAP dependencies and carefully decide what’s the best solution for your projects. I hope I could give you some hints what’s possible and what you have to watch. There will follow more blog posts about Helios and Target Platforms and P2 …..

3 responses

  1. Hi Ekkes,

    Useful blog…i think the having different workspaces with different target platform works
    more efficiently for me.Because in a same workspace if i change the target platform, my plug-ins take
    long time to compile.

    cheers,
    Saurav

  2. Hallo Ekkes,
    I am fighting with defining a target platform for an already existing RCP App. I read your article series in the eclipse Magazin (2.10-4.10) and I am now wondering if I can somehow compute all needed features/plugins for my set of application features and add them to my target platform.
    Finding bundles and selecting needed features manually is time consuming and error-prone (read: can’t be done). I thought maybe I can throw my update site and the galileo release location at p2 and have it compute what is needed to run my bundles? :-)

    • hi thomas,
      most important are the MANIFEST.MF where you declare all your dependencies. then its not so hard.
      you can also use bnd-tools or maven helping with dependencies, features, plugins….
      or read some books
      how to define your features and to decide which plug-in belongs to which feature is more a question about your project architecture -
      but there’s definitely no singlke button you hit and get all your work done by magic ;-)
      ekke

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

Follow

Get every new post delivered to your Inbox.

Join 1,067 other followers

%d bloggers like this: