Community
Participate
Working Groups
I've got Eclipse-platform-3.3M5 (I20070209-1006) On Linux-GTK-x86 (RHEL4) with Sun Java 1.6.0 Help > Software Updates > Find and Install New Remote Site: http://download.eclipse.org/eclipse/updates/3.3milestones JDT can be installed correctly from here. PDE needs to be found under M4 category (bug 175281). When selecting it, it's being downloaded but then Update Manager stops with an error (traceback see below). I'm almost 100% sure that this is because the feature is signed and packed, and there are some update manager issues with this: bug 163421, and bug 168583. Because packing is only enabled with Java 1.5 and later, the bug will most probably not appear with an 1.4 JVM so that would be a suitable workaround for clients. It might be considered to not sign and pack the features until this is resolved.
FYI, I used the [germany] Innoopract mirror for this. Here's the log of successfully getting org.eclipse.cvs from the site (I did this from the commandline with standaloneUpdate): !SESSION 2007-02-23 14:01:27.849 ----------------------------------------------- eclipse.buildId=I20070209-1006 java.version=1.5.0_10 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Framework arguments: -application org.eclipse.update.core.standaloneUpdate -command install -from http://mirror.yoxos-eclipse-distribution.de/eclipse.org/eclipse/updates/3.3milestones/site.xml -featureId org.eclipse.cvs -version 1.0.0 -to /folk/mober/RSETest/I20070223-0730/eclipse_ext/ep Command-line arguments: -data /folk/mober/RSETest/I20070223-0730/workspace -application org.eclipse.update.core.standaloneUpdate -command install -from http://mirror.yoxos-eclipse-distribution.de/eclipse.org/eclipse/updates/3.3milestones/site.xml -featureId org.eclipse.cvs -version 1.0.0 -to /folk/mober/RSETest/I20070223-0730/eclipse_ext/ep !ENTRY org.eclipse.update.core 4 0 2007-02-23 14:01:44.915 !MESSAGE Digest could not be parsed:Unable to retrieve remote reference "http://download.eclipse.org/updates/3.3milestones/digest.zip". [Server returned HTTP response code: "404 Not Found" for URL: http://download.eclipse.org/updates/3.3milestones/digest.zip.]
Here are the tracebacks from the log of trying to get PDE from the update site. I guess the most interesting part is this: java.lang.SecurityException: SHA1 digest error for lib/pdebuild-ant.jar Just like in bug 163421, this is a signed, packed bundle which contains a nested jar. !ENTRY org.eclipse.update.core 4 0 2007-02-23 15:15:43.925 !MESSAGE Digest could not be parsed:Unable to retrieve remote reference "http://download.eclipse.org/updates/3.3milestones/digest.zip". [Server returned HTTP response code: "404 Not Found" for URL: http://download.eclipse.org/updates/3.3milestones/digest.zip.] !ENTRY org.eclipse.update.core 4 0 2007-02-23 15:17:56.540 !MESSAGE Unable to remove "/folk/mober/RSETest/I20070223-0730/eclipse_ext/ep/eclipse/plugins/org.eclipse.pde.build_3.2.100.v20061210/lib" from the file system. [java.lang.Exception] !STACK 0 java.lang.Exception at org.eclipse.update.internal.core.UpdateManagerUtils.removeEmptyDirectoriesFromFileSystem(UpdateManagerUtils.java:343) at org.eclipse.update.internal.core.UpdateManagerUtils.removeEmptyDirectoriesFromFileSystem(UpdateManagerUtils.java:338) at org.eclipse.update.internal.core.SiteFilePluginContentConsumer.abort(SiteFilePluginContentConsumer.java:181) at org.eclipse.update.internal.core.SiteFileContentConsumer.abort(SiteFileContentConsumer.java:214) at org.eclipse.update.internal.core.FeatureExecutableContentConsumer.abort(FeatureExecutableContentConsumer.java:160) at org.eclipse.update.core.Feature.install(Feature.java:538) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:375) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:372) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:485) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) !ENTRY org.eclipse.update.core 4 0 2007-02-23 15:17:56.545 !MESSAGE Unable to remove "/folk/mober/RSETest/I20070223-0730/eclipse_ext/ep/eclipse/plugins/org.eclipse.pde.build_3.2.100.v20061210" from the file system. [java.lang.Exception] !STACK 0 java.lang.Exception at org.eclipse.update.internal.core.UpdateManagerUtils.removeEmptyDirectoriesFromFileSystem(UpdateManagerUtils.java:343) at org.eclipse.update.internal.core.SiteFilePluginContentConsumer.abort(SiteFilePluginContentConsumer.java:181) at org.eclipse.update.internal.core.SiteFileContentConsumer.abort(SiteFileContentConsumer.java:214) at org.eclipse.update.internal.core.FeatureExecutableContentConsumer.abort(FeatureExecutableContentConsumer.java:160) at org.eclipse.update.core.Feature.install(Feature.java:538) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:375) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:372) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:485) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) !ENTRY org.eclipse.core.jobs 4 2 2007-02-23 15:17:56.566 !MESSAGE An internal error occurred during: "Update Manager". !STACK 0 java.lang.SecurityException: SHA1 digest error for lib/pdebuild-ant.jar at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:194) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:201) at java.util.jar.JarVerifier.update(JarVerifier.java:188) at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:411) at java.io.InputStream.read(InputStream.java:85) at org.eclipse.update.internal.core.UpdateManagerUtils.copy(UpdateManagerUtils.java:935) at org.eclipse.update.core.Utilities.copy(Utilities.java:172) at org.eclipse.update.internal.core.UpdateManagerUtils.copyToLocal(UpdateManagerUtils.java:237) at org.eclipse.update.internal.core.SiteFilePluginContentConsumer.store(SiteFilePluginContentConsumer.java:90) at org.eclipse.update.internal.core.PluginEntryContentConsumer.store(PluginEntryContentConsumer.java:37) at org.eclipse.update.core.Feature.install(Feature.java:464) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:375) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:372) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:485) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
I guess the simplest fix for this would be to delete plugins/org.eclipse.pde.build_3.3.0.v20070209.jar.pack.gz such that this particular bundle is not available in packed form. In addition to that, it might also be necessary to deal with the Eclipse.inf file in order to disable signing and/or packing the nested jar pdebuild-ant.jar That's what helped for us with org.apache.commons.net - see bug 163421
FYI, the META-INF/Eclipse.inf that I'm using for commons.net looks like this: #do not sign individual entries of nested jars; #sign the archive as a whole instead #also do not pack until bug [163421] is resolved jarprocessor.exclude.children.pack = true jarprocessor.exclude.children.sign = true
Dejan, this looks important for 3.3 since everyone is moving to signed/packed bundles.
I got the same error when I try to install signed,packed BIRT features which has nested jars in JDK 1.5. Those features which doesn't have nested jars but have plugins in folder format after installing encounter the same problem(com.lowagie.itext).
(In reply to comment #4) > FYI, the META-INF/Eclipse.inf that I'm using for commons.net looks like this: > #do not sign individual entries of nested jars; > #sign the archive as a whole instead > #also do not pack until bug [163421] is resolved > jarprocessor.exclude.children.pack = true > jarprocessor.exclude.children.sign = true Martin, Thanks for providing this workaround. But I tried adding this inf in plugins' META-INF folder, below exception was still thrown out: !ENTRY org.eclipse.core.jobs 4 2 2007-03-21 16:59:04.423 !MESSAGE An internal error occurred during: "Update Manager". !STACK 0 java.lang.SecurityException: SHA1 digest error for META-INF/eclipse.inf at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:196) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:201) at java.util.jar.JarVerifier.update(JarVerifier.java:188) at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:403) at java.io.InputStream.read(InputStream.java:89) at org.eclipse.update.internal.core.UpdateManagerUtils.copy(UpdateManagerUtils.java:913) at org.eclipse.update.core.Utilities.copy(Utilities.java:172) at org.eclipse.update.internal.core.UpdateManagerUtils.copyToLocal(UpdateManagerUtils.java:237) at org.eclipse.update.internal.core.SiteFilePluginContentConsumer.store(SiteFilePluginContentConsumer.java:90) at org.eclipse.update.internal.core.PluginEntryContentConsumer.store(PluginEntryContentConsumer.java:37) at org.eclipse.update.core.Feature.install(Feature.java:464) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:375) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:372) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:485) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) The Eclipse I used to install is M5enh. Am I missing any settings?
(In reply to comment #7) Xiaojing, I'm sorry this did not work for you but I have no other solution. For our own project, this helped for commons.net but failed for other bundles. I just gave up trying to sign my bundles. I think this is a bad bug in the Platform, and there is nothing we can do to work around it until the bug is finally found and fixed. At the Europa Meeting at EclipseCon, Platform PMC Lead Kevin Haaland promised to get those Update Manager bugs that are blocking for Europa fixed as soon as possible. Unfortunately, though, it looks like the bug is still in 3.3M6 so I'd recommend not wasting any more time with trying to sign.
Martin, thanks for your infomation!
Both dependent bugs have been fixed. Please retry with the next M6 candidate build.
I'm afraid it's not that easy to verify before M6 is released, since the 3.3milestones update site contains stuff from M5 so if I use it with M6 it must fail... Kim, do you have a test update site that gets filled with stuff from I-builds leading up to M6, before M6 is released?
Tried it out with I20070321-1800 on Linux-RHEL4 / Sun 1.6.0, exactly following the steps from the description. Found that the issue is NOT FIXED yet although the fix for bug 163421 is verified in this build. This means that either the plug-ins on the Platform's milestone update site are not signed properly (they are pretty old already, so it is likely that a newer version of basebuilder / jarsigner would create more correct results). Or, there is yet another bug in the update manager client. At any rate, it needs to be tested again as soon as the Platform provides a test update site with latest signed jars towards M6.
Created attachment 61671 [details] log file with UM exceptions in I20070321-1800
Note that having this bug sill open means that for Europa M6, it is necessary to go to the Discovery site with eclipse-SDK installed whereas the plan for the final Europa release is that starting with the Platform should be sufficient. I consider this important since many consumers will be interested in the Runtime only, so they would not want to download the sources and ISV docs which are in the SDK. But there is no platform runtime which also includes JDT and PDE. The PDE Runtime, though, is required by some Europa projects.
Try http://download.eclipse.org/eclipse/testUpdates This is where the updates go for our integration builds.
Reassigning to platform-releng since manual verification of the pde.build bundle shows that it is indeed not signed properly: the nested pdebuild-ant.jar file is not signed, but the eclipse.inf file has no information that it should not be signed. I'm not 100% clear whether we do want to sign nested jars (I think we do?) so the bug is with the sign script or releng process; or we do not want to sign nested jars, so the bug is with the UM verifier which tries to verify it. My personal feeling is that the nested jar should be signed, since this plugin is going to be exploded in the user's installation thus the original signatures of the UM jar will no longer be available. This needs to be re-tested with a recent basebuilder / M6 drop. Below are the steps I took for manual verification. Note that the older jar (pde.build_3.2.100.v20061210) gives exactly the same results. > unpack200 org.eclipse.pde.build_3.3.0.v20070209.jar.pack.gz y.jar > jarsigner -verify y.jar jar verified. Warning: This jar contains unsigned entries which have not been integrity-checked. > mkdir y > cd y > jar xf ../y.jar > cd lib/ > unpack200 pdebuild-ant.jar.pack.gz a.jar > jarsigner -verify a.jar jar is unsigned. (signatures missing or not parsable)
Trying it from http://download.eclipse.org/eclipse/testUpdates loads org.eclipse.pde.build_3.3.0.v20070321.jar.pack.gz but yields exactly the same results: verification fails both manually and in UM. I looked at HEAD of the pde.build plugin, and noticed that there is file src_ant/META-INF/eclipse.inf which disables signing. But in the final deployed plugin, this file is no longer there. So, the bug either is that eclipse.inf gets lost during the deployment process, or that it should not be there in the first place. My personal preference would be to allow signing it, but this is for others to decide. Reassigning back to platform releng to decide.
I just downloaded I20070321-1800. The pdebuild-ant.jar does contain an eclipse.inf which has a jarprocessor.exclude.sign = true. We do not want to sign this jar for the same reasons that the org.apache.ant/lib/*.jars aren't signed. However, this is irrelevant to this problem. The outer jar is signed and it fails verification after unpacking. Martin, your test in comment #16 was not sufficient, you only used unpack200, which would not have recursively unpacked the nested jar, hence the warning about unsigned entires. I downloaded org.eclipse.pde.build_3.3.0.v20070321.jar.pack.gz from the update site and unpacked it with java -jar jarprocessor.jar -unpack org.eclipse.pde.build_3.3.0.v20070321.jar.pack.gz The result fails verification, I don't yet know why.
The pdebuild-ant.jar is excluded from signing at denoted by the eclipse.inf in the repository see org.eclipse.pde.build/src_ant/META-INF/eclipse.inf jarprocessor.exclude.sign=true This also exists in the resultant jar produced by the build process in the pdebuild-ant.jar cat eclipse.inf #Processed using Jarprocessor jarprocessor.exclude.sign = true pack200.args = -E4 pack200.conditioned = true I updated from I20070321-1300 -> I20070321-1800 without an issue using http://download.eclipse.org/eclipse/testUpdates. But I'm using an older vm and windows. I'll try on a Linux box with the Sun 1.6 vm.
(In reply to comment #18) > Martin, your test in comment #16 was not sufficient, you only used unpack200, > which would not have recursively unpacked the nested jar, hence the warning > about unsigned entires. If you read a little further, you see that I also manually did the recusive expand, unpack and verify. Which failed, of course, since pdebuild-ant.jar is not signed. What I did forget, is extract META-INF from the nested jar and, voila, eclipse.inf is indeed there stating that it is not to be signed! So it looks like the bug is indeed in the client: manual unpack and verify shows that everything is ok because pdebuild-ant.jar is not meant to be signed, but it looks like UM does not take the eclipse.inf from the nested jar into account which says that it should not be signed! A valid workaround might be to specify the following line in the parent jar's META-INF/eclipse.inf: jarprocessor.exclude.children.sign = true
Created attachment 61699 [details] replicated the problem with sun 1.6 vm and rhel 4 in lab attaching .log
Moving back to update and adding pde build as cc for comment regarding updating pde build's top level eclipse.inf as described in comment #20
Andrew?
I think the problem is as follows: all of the repack (pack200 -r), unpack200, and jarsigner tools leave their results in slightly different formats with respect to the compression of the resulting jar (mostly around whether crc & size information goes before or after a record entry). This may depend on the OS & VM used. Because of this, when nesting jars inside of something that is being signed, the jarprocessor performs a "normalization" step on the nested jars to ensure that they are always the same. It appears that by skipping the signing on the nested jars, we are also skipping one of the normalization steps resulting in nested jars whose contents are identical, but where the jars themselves have different bytes because of the crc & size info moving around. I don't believe that the eclipse.inf changes mention in comment #20 would fix things. I believe the same problem should exist for org.apache.ant, but is just not being seen since I doubt it changed since I20070209-1006. A fix for this bug would need be needed for the update/jarprocessor that is doing the conditioning/signing, it would not be needed for update as a client.
I think pde.build could work around this adding jarprocessor.exclude.pack=true in addition to the jarprocessor.exclude.sign in the nested eclipse.inf file.
The pde build submission in the I200700322-1800 build fixed the issue. I just tried updating from I20070321-1800 to I200700322-1800 on RHEL 4 with a 1.6 vm and confirmed that it was successful. Thank you Martin for your persistence on this bug. It made a real difference and we avoided having a serious issue for M6 Europa consumers. I'll update to a new version of the jar processor in basebuilder when it is available and coordinate with the webmaster to install a new one at build.eclipse.org
Note that because of bug 178882, pde.build currently specifies jarprocessor.exclude.children=true and neither of the nested jars are signed or packed
I think that PDE should be good now (3.3M6) but since PDE depends on JDT, the Europa M6 site still does not work due to bug 179270.
I get this crash every day now, and have for a long time, with Eclipse 3.2.2 Version: 3.2.2 Build id: M20070212-1330 I find it totally and utterly incomprehensible that a bug that manifests itself _every single day_, for every user that have the auto-update feature turned on, cannot be found and eliminated in such a long time. It should have taken at most a couple of days - and preferably it should never have been released. The same stuff happened some time ago with the idiotic bug 167016. It's just annoying, but oh how annoying.
This should have been fixed for some time now. Do you still see this problem?
Me? Yes. I just tried again, and I get it again. The four packages in the BIRT thingy consistently gives errors. I tried this brand new one here: org.apache.commons.codec_1.3.0.v20070531 And get.. java.lang.SecurityException: SHA1 digest error for META-INF/eclipse.inf at sun.security.util.ManifestEntryVerifier.verify(Unknown Source) at java.util.jar.JarVerifier.processEntry(Unknown Source) at java.util.jar.JarVerifier.update(Unknown Source) at java.util.jar.JarVerifier$VerifierStream.read(Unknown Source) at java.io.InputStream.read(Unknown Source) at org.eclipse.update.internal.core.UpdateManagerUtils.copy(UpdateManagerUtils.java:913) at org.eclipse.update.core.Utilities.copy(Utilities.java:172) at org.eclipse.update.internal.core.UpdateManagerUtils.copyToLocal(UpdateManagerUtils.java:237) at org.eclipse.update.internal.core.SiteFilePluginContentConsumer.store(SiteFilePluginContentConsumer.java:90) at org.eclipse.update.internal.core.PluginEntryContentConsumer.store(PluginEntryContentConsumer.java:37) at org.eclipse.update.core.Feature.install(Feature.java:464) ... (and two "unable to remove" exceptions).
This is a problem with the Birt archives. Moving to releng - please move further if not the right inbox.
Moving to BIRT. It might be a similar issue as we saw with the jcraft jar - the jar was signed, then an about.html was added that invalidated the signature. If you verify the org.apache.commons.codec jar in question and it doesn't verify - then you know this is the same issue and will have to follow up with the team that contributed this jar to Orbit.
(In reply to comment #31) > Me? Yes. I just tried again, and I get it again. > The four packages in the BIRT thingy consistently gives errors. I tried this > brand new one here: > org.apache.commons.codec_1.3.0.v20070531 > And get.. > java.lang.SecurityException: SHA1 digest error for META-INF/eclipse.inf > at sun.security.util.ManifestEntryVerifier.verify(Unknown Source) > at java.util.jar.JarVerifier.processEntry(Unknown Source) > at java.util.jar.JarVerifier.update(Unknown Source) > at java.util.jar.JarVerifier$VerifierStream.read(Unknown Source) > at java.io.InputStream.read(Unknown Source) > at > org.eclipse.update.internal.core.UpdateManagerUtils.copy(UpdateManagerUtils.java:913) > at org.eclipse.update.core.Utilities.copy(Utilities.java:172) > at > org.eclipse.update.internal.core.UpdateManagerUtils.copyToLocal(UpdateManagerUtils.java:237) > at > org.eclipse.update.internal.core.SiteFilePluginContentConsumer.store(SiteFilePluginContentConsumer.java:90) > at > org.eclipse.update.internal.core.PluginEntryContentConsumer.store(PluginEntryContentConsumer.java:37) > at org.eclipse.update.core.Feature.install(Feature.java:464) > ... > (and two "unable to remove" exceptions). Are you using Eclipse Version: 3.2.2 Build id: M20070212-1330 to install BIRT features you mentioned(org.apache.commons.codec_1.3.0.v20070531)? Feature with this version is under BIRT2.2 category. It's for BIRT2.2 and should be upgraded thru Eclipse 3.3, which has fixed bugs of signed/packed jars. I have installed newest BIRT 2.2 features with Eclipse 3.3I20061214-1445 without any exceptions on JDK1.5(windows).
Sorry, my eclipse version is: Version: 3.3.0 Build id: I20070323-1616
I've not done anything to ask for these features in particular - they just pop up in the nightly run of update manager ("Automatic Updates"), and also whenever i run a new Software Updates -> Find and Install -> Search for updates of the currently installed features. I have EclipseSQL, Spring IDE, Subversive and testng update sites in addition to what I got from the Callisto stuff (isn't it? - the thing about ten projects releasing together). That's it. Why do I have this problem? Why would it have anything to do with anything which version of Eclipse I'm using, by the way? Shouldn't signatures check out, regardless of what I'm checking them out with?!
BIRT currently has used signed/packed update jars for Europa. And only since Eclipse 3.3M6, #163421 was fixed and you can download and extract signed and packed update jars. I don't know if this fix will be released to next Eclipse 3.2.X release. Feature org.apache.commons.codec_1.3.0.v20070531 is for Europa, so you will get the packed signed jars while using UM, which cause the problem. There's another version of org.apache.commons.codec feature on update site, which is for Callisto and is not signed/packed. I don't know how to select older version of certain feaure in automatic updates. One solution is just removing packed files(.gz)of these third party features from update site. Another is using JDK1.4 to do automatic updates, so those .gz files won't be downloaded.
This bug is still not fixed. I have gotten these errors every single day UM runs. It is SO annoying. I wonder, isn't this affecting *every single user* of Eclipse, or do I have something extraordinary setup?? It crashes on com.lowagie.itext_1.5.2.v20070608-041w31181642 and the other three packages of BIRT. It might be another type of error now..: Error: Unable to complete action for feature "Lowagie iText Feature" due to errors. org.eclipse.core.runtime.CoreException: Verification of feature unsuccessful. Installation cancelled. [java.lang.NullPointerException] at org.eclipse.update.core.Utilities.newCoreException(Utilities.java:223) at org.eclipse.update.core.Utilities.newCoreException(Utilities.java:254) at org.eclipse.update.core.Feature.verifyReferences(Feature.java:981) at org.eclipse.update.core.Feature.install(Feature.java:377) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:375) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:372) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:485) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) org.eclipse.core.runtime.CoreException[0]: java.lang.NullPointerException at org.eclipse.update.internal.verifier.CertVerifier.alreadyValidated(CertVerifier.java:221) at org.eclipse.update.internal.verifier.CertVerifier.verify(CertVerifier.java:152) at org.eclipse.update.internal.verifier.CertVerifier.verify(CertVerifier.java:133) at org.eclipse.update.core.Feature.verifyReferences(Feature.java:967) at org.eclipse.update.core.Feature.install(Feature.java:377) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:375) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:372) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:485) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) With an "under-error": Verification of feature unsuccessful. Installation cancelled. [java.lang.NullPointerException] java.lang.NullPointerException at org.eclipse.update.internal.verifier.CertVerifier.alreadyValidated(CertVerifier.java:221) at org.eclipse.update.internal.verifier.CertVerifier.verify(CertVerifier.java:152) at org.eclipse.update.internal.verifier.CertVerifier.verify(CertVerifier.java:133) at org.eclipse.update.core.Feature.verifyReferences(Feature.java:967) at org.eclipse.update.core.Feature.install(Feature.java:377) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:375) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:372) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:485) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) Heres the Session Data: eclipse.buildId=M20060629-1905 java.version=1.6.0_01 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=no_NO Command-line arguments: -os win32 -ws win32 -arch x86
As you mentioned above, your eclipse version is 3.2.0 release eclipse.buildId=M20060629-1905 java.version=1.6.0_01 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=no_NO Command-line arguments: -os win32 -ws win32 -arch x86 The signed and packed jar only works with Eclipse platform 3.3M6 or later. Please upgrade your eclipse platform.
Dude, I have never done anything to ask for these things to "come to me" and try to install themselves and ALWAYS fail! I have merely installed 3.2, and from then on the Update Manager runs every night. Why on earth shouldn't this work???? I don't wanna use milestones. I want the stable release, and I'd expect the _built in Update Manager_ to work on the _stable releases_ - or isn't this expected in the Eclipse community? Give me a clue how to get rid of these absolutely idiotic daily errors on my current stable version installation (3.2) of your product, bar from upgrading to a random unstable code-cut? I don't rule out that this somehow is my fault - but what have I done wrong, and how may I fix it?
Milestone update jars will be pushed to update site, this is not only for BIRT. I'm not sure if *Auto update* is what you want? If not, you can just close the auto update option. I have attached the setting below. If you'd like to update with the newest release, you can just update it manually when you need. Since usually release take once a year not every night...
Created attachment 72129 [details] Auto update option setting Closed the auto update option. Manually choose updates of BIRT 2.1.X will solve the problem
Created attachment 72134 [details] Choose features for Eclipse 3.2.X under 2.1 category snap
Thanks for those images - I've only used Eclipse for the past 3 years, so it was really great to get a good visual explanation of how to do these things! :) So, what you're telling me, is that I should not use the auto update feature for an installed stable release of Eclipse? In comparison to every other modern computer program of some size, Eclipse do not actually support periodic updates to an installed stable release, even though it clearly has a subsystem and options for this? Oh well.. Do note that the BIRT packages are _the only_ subsystem that gives these problems (again at least on my installation). I cannot grasp why it wouldn't be possible for the Eclipse developers to either backport a working signature check to 3.2, OR simply make it possible for the BIRT updates to be installed to an existing Eclipse 3.2 system. But then again, I'm just a simple user of Eclipse, not a developer. BTW: The summary is wrong for me - i cannot install it on Windows.
(In reply to comment #44) > Do note that the BIRT packages are _the only_ subsystem that gives these > problems (again at least on my installation). I cannot grasp why it wouldn't be ... I'm not sure if all projects in Europa have used signed and packed jars. Eclipse update site URL for 3.2 is http://update.eclipse.org/updates/3.2, which has not used signed and packed jars while update site URL for Europa is: http://update.eclipse.org/updates/3.3. So you won't get such error while updating Eclipse platform. But BIRT's update site URL for 2.1.X and 2.2.X are all http://download.eclipse.org/birt/update-site. But they are in different category. I guess that *auto* updater will find the newest feature to install which leads to the problem, while it can be avoid by update manually.
schedule for BIRT 2.3 M4 to follow up/verify this bug.
Mark this bug as fixed. The root cause for this issue exists for BIRT installation is that we used same URL for 2.1.x(Callisto) and 2.2.x(Europa). And we used signed and packed jars for 2.2.x. Users who met such issues are trying to install 2.2.x on Eclipse 3.2.x build. And it will thrown exceptions when installing signed/packed jars on Eclipse platform earlier than 3.3M6. Since jar signing is not "Must Do" requirement of Europa, we moved all .gz files on update site for 2.1.X and 2.2.X for uploaded files. For the later Winter maintainence release, we will upload packed jars only(without signing). We used a new URL for 2.3.x (Ganymede), which will use signed and packed jars.
