Brand your Feature and be part of “About Eclipse”

You’re writing plug-ins running inside Eclipse ? Then let the users know that your plug-ins are included.

To check what is installed into your running Eclipse IDE go to menu “About Eclipse” and click on “Installation details” – there you’ll get all about installed Plug-ins, features, etc.

But wait – if you open “About Eclipse” there are some icons visible like this:

Without looking on the Installation details you see some Icons per ex. from Eclipse Modeling Project:

one click and you get informations about the features you installed from Modeling Project:

For each feature you get a description with Icon and even Links pointing directly to the Project sites.

Whats the secret to be visible with your project icon and feature descriptions ?

Feature Branding

Open your feature.xml and you can point to a branding plugin:

The Branding Plug-in normaly is one of the plug-ins from your feature, but you can also use an extra branding-plug-in.

Inside your Branding Plug-in you have to place some informations at the root of your plug-in project:

• about.ini
• nameOfYourFeatureImage

about.ini is a properties file with minimum two entries:

featureImage=nameOfYourFeatureImage
aboutText=your text to be displayed

here’s an example:

the content of the about.ini:

I did this with the redView Features: one plug-in of each Feature works as a branding Plug-in with always the same Feature Image.

Then after installing these features you’ll see it at “About Eclipse”:

If you want to know what else you can do with branding, I recommend the eclipse Plug-ins book from Eric Clayberg and Dan Rubel, which belongs to my most important eclipse books:

I hope you got an idea how to better present your Features and Plug-ins at “About Eclipse”.

[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 …..

P2 is my friend again

If you follow my blogs, then you know about some problems I ran into. the pain starts the week before EclipseCon where suddenly RAP plug-ins are installed into the IDE.

It’s great that more and more projects now are supporting RAP and RCP – redView will follow soon. To support RAP and RCP both together there are some optional dependencies like this:

You see: both Plug-ins – the RCP and the RAP version – are optional. Now it’s up to you to provide the right Plug-in, then other Plug-ins with dependencies to packages from jface, swt etc. can work under both environments.

If using Target Platform definitions you’re free to organize your Target Platform the right way. there are use-cases where only RCP or only RAP or both are used. If you only need one specific UI – Environment in your TargetPlatform and still want to use “include required software” if adding software-sites:

it may help to tell the Target Platform to always include some plug-ins. Unter tab “Environment” you can do this:

In this case the Target Platform will include all from SWT – so if you don’t explicitely include RAP SDK – you’ll only get plug-ins from RCP.

Using Launch Configurations and building Products its up to you to combine the bundles you need.

The problems I run into was that P2 installs RAP bundles into the IDE where you don’t have control, because all was managed by P2 behind the scenes.

And now – starting with Helios M6 – it happened that P2 was resolving dependencies while installing new software or updating.

The solution to avoid that P2 is too greedy is to add a p2.inf inside the META-INF folder of the plug-ins with optional dependencies to RAP:

Now P2 is aware of this and no more RAP bundles in your IDE

The way to make it all run was hard, I don’t remember since all the years to report so many bugzillas and to do so many tests where you always have to start with a fresh installation to avoid getting things wrong from caches or bundlepools.

Thanks to all helping…

… to make it run for Helios. And to make it clear, because in previous blogs I reported about problems with P2, RAP, Riena,… – no one was guilty. This was a new situation and all happens in very complex environments. (And as Pascal says “Don’t shoot P2 – P2 was only the messenger” )

Developers from so many teams have spent much time to understand and help. This was again a really great experience how much fun it is to be part of the Eclipse Community.

now – after 5 weeks – back to normal work on redView. Starting with Helios M7 you’ll be able to install redView easy and we’ll also provide the workshop from EclipseCon in working environments stay tuned…. I’ll blog about…