redView + p2 + helios == sleepless nights

lets start with the good news:

this weekend redView 0.7.4 will be available together with detailed instructions how to install please wait for another blog entry this weekend before installing from updatesite or cloning the source repository. btw: our sources (Mercurial) will be available from Sourceforge, bitbucket and also EclipseLabs !

if you follow my blogs then you know about the pain from last weeks to make redView run under Helios. it starts friday before EclipseCon and was a blocker to have a successfull redView workshop at EclipseCon. Three weeks ago I thought the story ends as I reported “P2 is my friend again“.

Remember the movie “Groundhog Day” ? (“und täglich grüßt das Murmeltier” in Germany) – that’s how I’m feeling: after each Helios Milestone +3 it happens again: P2 installs unwanted optional dependencies into the IDE (Bugzilla 312547): in this case RAP plug-ins causing trouble to IDE and Target Platform Definitions where the active Eclipse is used as starting point.

BTW: P2 still is my friend there’s no one to blame about the problems, they happen only if you’re using some projects / tools / update sites together and thanks to Eclipse release plan and thanks to the Eclipse release train (around 40 projects this year) there’s a chance to find it before Helios (Ecipse 3.6) will be released.

Thanks to Pascal, Christian and uncount others spending so much time to find solutions. As a result of their hard work it becomes better from Milestone to Milestone: in M6 it happens each time that RAP was installed into the IDE, now using M7 / RC1 it happens only randomly: I did many time-consuming tests always installing some plug-ins into fresh Helios SDK under OSX, Windows 7 and Ubuntu and 4 of 10 installations failed.

At the moment it isn’t clear why it fails randomly (see Bugzilla 312547) – all needed informations for P2 are provided by Riena (… greedy=false in p2.inf …) so there should be no reason to fetch and install optional RAP bundles too.

The current solution, that all plug-ins with optional dependencies to RAP tell p2 not to be so greedy, seems not to work in all cases and there’s a small back door where RAP bundles come in again.

There’s also some work on bugzilla 306709 to go the opposite way: let RAP and SWT define P2 metadata that they conflict with each other. Then it should be easy for P2 to do the right work while installing Plug-ins into IDE: SWT is always there, so no RWT etc will be installed.

Hopefully this could be done for Helios, because more and more projects will support RAP (and perhaps more runtime technologies in the future).

If you run into those scenarios where your IDE doesn’t work anymore (Views couldn’t be opened etc) then perhaps you got RAP bundles in.

My workarounds at the moment:

• after installing new software, don’t restart
• at first look into “Plug-ins” View if there are org.eclipse.rap.* plug-ins.
• If you found some: quit Eclipse and remove them from /eclipse/plugins folder.
• then restart Eclipse.

If you define or use a Target Platform definition based on active running Eclipse, then you’ll get some errors:

simply ignore them – the Target Platform will still work.

As already mentioned above: redView 0.7.4 will be available this weekend and you can try it out if you’re not afraid to deal with such problems.

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…

Who eats the categories from update-sites -> part 2: workaround

on sunday I blogged about the problems with lost or wrong Categories if UpdateSites are build using PDE. Thanks to the great Eclipse Community – even on a sunday I got some comments and also tips through twitter some minutes or hours later

If you also have trouble using Categories in your Update-Site then take a look at the comments I got here.

I got also confirmation that this behaviour wasn’t expected and opened Bugzilla 309624.

For now I’m using this as workaround based on this P2 wiki page about P2 Publisher.

After generating the Update-Site from PDE I have to run two headless applications:

P2 UpdateSitePublisher

java -jar <eclipseInstallation>/plugins/org.eclipse.equinox.launcher_*.jar
-application org.eclipse.equinox.p2.publisher.UpdateSitePublisher
-metadataRepository file:/<repo location>/repository
-artifactRepository file:/<repo location>/repository
-source /<location with site.xml>
-compress
-publishArtifacts

as Source Location I can use the generated UpdateSite.

P2 CategoryPublisher

this publisher uses the generated /repository from the P2 UpdateSitePublisher and can re-use the sites.xml from PDE Update Site Project:

java -jar <eclipseInstallation>/plugins/org.eclipse.equinox.launcher_*.jar
-application org.eclipse.equinox.p2.publisher.CategoryPublisher
-metadataRepository file:/<repo location>/repository
-categoryDefinition file:/<location with site.xml>/sites.xml
-categoryQualifier
-compress

The P2 CategoryPublisher modifies the generated repository.

Then I published the content of the P2 /repository to my Update Site online and now the Categories work well.

Thanks to all helping with tips.

Would be great if the P2 UpdateSitePublisher and CategoryPublisher could run as ANT tasks to avoid headless builds in this use-case, but there are only ANT tasks for the P2 FeaturesAndBundles Publisher and the P2 ProductPublisher. So I opened Bug 309663.

ekke