Community
Participate
Working Groups
Created attachment 97500 [details] updatesites.zip Build ID: 3.4 M6 Overview of problem: If a profile uses two update sites that declare the same feature, but the feature is missing on one update site, provisioning fails. Our expectation is that if the feature can be found on ANY update site it should be resolved. In a perfect world a warning about the missing feature on the broken update site would also be generated. Secondary issue that is related to this problem: Repositories are traversed in random order based on hashcodes. This produces non-reproducible behavior and decreases reliability. Steps To Reproduce: (first steps are to get around file:// urls) 1. Install a lamp install (for example, xampp) 2. Unzip the two update sites to your local drive (see attachment) 3. Setup your lamp install to alias /updatesite1 and /updatesite2 to the two update sites from the attachment. (actual setup of bug) 4. In a new profile, add feature 1 from http://localhost/updatesite1 and feature 2 from http://localhost/updatesite2. 5. After creating the profile, but before installing it, move the feature jar for com.example.helloworld1.feature in update site 2 so it cannot be found. At this point, updatesite1 should be a valid update site and updatesite2 should be broken because it cannot find the com.example.helloworld1.feature feature. 6. Try to install, you MAY get an exception like what is found at the bottom of this bug report. I say may because this appears to be VERY hashcode dependent. The order repos are processed can (and often do) change between sessions. ERROR: Error closing the output stream for org.eclipse.releng.tools/org.eclipse.update.feature/3.2.100.v20070122-32-7w31181523 on repository file:/C:/Program Files/Pulse/Common/. java.io.IOException: Error unzipping C:\DOCUME~1\DEVELO~1\LOCALS~1\Temp\org.eclipse.releng.tools_3.2.100.v20070122-32-7w3118152330403.jar: Invalid zip file form at at org.eclipse.equinox.internal.p2.core.helpers.FileUtils.unzipFile(FileUtils.java:31) at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository$ZippedFolderOutputStream.close(SimpleArtifactRepository.java:135) at java.io.FilterOutputStream.close(Unknown Source) at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository$ArtifactOutputStream.close(SimpleArtifactRepository.java:73) at org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.perform(MirrorRequest.java:123) at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:426) at org.eclipse.equinox.internal.p2.artifact.repository.simple.DownloadJob.run(DownloadJob.java:64) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) More information: I've included all of the setup projects in the attachment to ease setup.
Jed, Tim do you plan on doing anything on these issues for 3.4?
What makes this really bad is that the entire update is not transactional - when the mentioned problems happens, the update process leaves me with a partial install of some of the dependencies which I don't see anywhere from the update UI. I would expect that the entire update fails before changing anything on disk, or that any performed changes are rolled back if an unexpected problem occurs during the update process. Major for me.
Jed I think that the original problem has been fixed in RC3 with the robustness improvements that have been done to the download. Are you still experiencing this problem? > the update process leaves me with a partial install of some of the dependencies which I don't see anywhere from the update UI. Tom, could you please add more details about what is left behind? After the failure, can you system come back up again?
(In reply to comment #3) > Tom, could you please add more details about what is left behind? After the > failure, can you system come back up again? - The system *does* come up - he plug-ins that make up my additional features (except the one that failed due to the exception at hand) plus all dependencies are downloaded to <eclipse_install>/plugins and <eclipse_install>/features - those plug-ins are not referenced in <eclipse_install>\configuration\org.eclipse.equinox.simpleconfigurator\bundles.info - fixing the update site and re-running the update will download the missing plug-in and install all the features. I guess this means that the update mechanism just stores the plug-ins in within the installation area, but does not actually install them. You may argue that this isn't exactly a "partial install", but to me it still is for those reasons: 1. my installation *was* changed by the update manager - otherwise, no plug-ins would be stored in the plugins folder. If they are just stored as download cache, then that cache area should reside somewhere else than amongst all other installed plug-ins, e.g. in my temp dir, or in %Local Settings%/... 2. I cannot remove the downloaded plug-ins (the "Revert Configuration" button in the update dialog does not change anything. In short: if the downloaded updates were stored somewhere else, I couldn't claim a partial installation.
The initial issue had been addressed 3.4. The fact that the plugins are located as siblings of the eclipse.exe is a configuration option (for example in some cases the plug-ins are in a bundle pool shared across several instances) and we don't plan to put the files in another location.
