Description David Williams 2010-10-01 02:49:20 EDT

This may be similar to bug 272251, but seems a little different somehow. 

We have started to prepare patches (already) to be installed on top of Helios SR1. We've discovered they install correctly if installed into a "pure" p2 installed product (such as an EPP Java JEE package) but, if the prereqs are just unzipped on top of Eclipse SDK (either literally, or in the dropins folder) then the patches appear to install but only some of them do ... 5 or so installed, 5 or so not installed ... but there are no errors/warnings, etc. 

So ... even if we have made an error somehow (as we did in bug 272251) then this is causing a problem since there's no error given to users (or us!). 

Is there some debug switch we could turn on to help spot errors in our patch features? We've proof read the patch features very carefully. If we have not made some silly error, then this might be a regression, as we have done similar patches and steps on top of previous releases.

To reproduce, you can get the "prereq" zips and our archived p2 repo of patch features from following (temporary) URL 

http://download.eclipse.org/webtools/patches/drops/R3.2.2/P-3.2.2-20100930175048/

I've tried a half dozen ways of installing various combinations, but the following steps show the failure:

Unzip following to a common directory: 

eclipse-SDK-3.6.1-win32.zip
emf-xsd-SDK-2.6.1.zip
GEF-SDK-3.6.1.zip
dtp-sdk_1.8.1.zip
wtp-R-3.2.2-20100915173744.zip

Start that client, and then use Eclipse "install new software" to install the archived p2 repository that contains patch features. (You can select all, and yes, we know there are two categories with same content right now ... we'll fix that, but seems unrelated to this problem). 

wtp-patches32x-buildrepo-P-3.2.2-20100930175048

You'll see everything seems ok, but once you restart and go back to install new software for those patches, there's still two features that show they can still be installed (but even trying again won't install them). 

This sequence and mix of using unzip and using p2 seems critical to reproducing. From my tests, if p2 is used for everything, or if unzip is used for everything, then the patch features are installed and work as expected. 

So, while maybe an odd combination of unzipping and using p2 ... it happens to be the way we ended up doing it for the unit tests for this case so showed up right away. 

I thought I should report it, since it might be the "tip of the ice berg" to some behavior change that is more important than this one use case ... not to mention it might indicate some subtle problem in our patch features that will effect future installs, or something. 

So, main bug might be that errors are not reported ... but also that the install fails sometimes, but succeeds in other cases ... very confusing.