Community
Participate
Working Groups
Doing some testing for bug 132450. Found an apparent problem with org.eclipse.jdt.core_3.3.0.v_745.jar and/or org.eclipse.jdt.core_3.3.0.v_755.jar when trying to install via UM. Steps to reproduce: 1. download Platform Runtime Binary 3.3.0M7 from http://fullmoon.torolab.ibm.com/downloads/drops/S-3.3M7-200705031400/linPlatform.php#EclipseSDK 2. unpack, use clean workspace. Here's my script: #!/bin/bash rm -fr /tmp/workspace-clean eclipse tar xzf eclipse-platform-3.3M7-linux-gtk.tar.gz ./eclipse/eclipse -vm /opt/sun-java2-5.0/bin/java -data /tmp/workspace-clean -consolelog & 3. log console errors to file (see attached files) 4. launch Eclipse. Dispose Welcome screen (click the X). 5. Help > Software Updates > Find and install... 6. Search for new features to install > Next 7. [x] Europa Discovery Site (or you can add the staging site -- either one fails: http://download.eclipse.org/releases/europa/staging/site.xml) 8. select main Eclipse.org mirror (bottom of the list) 9. expand twisty 'Europa Discovery Site' (or staging site) 10. expand twisty 'Java Development' *** WAIT up to 5 seconds if using staging site *** 11. [x] Eclipse Plug-in Development Environment 3.3.0 12. click 'Select Required' *** WAIT up to 90 seconds if using staging site *** 13. click Next, accept licenses, Next > Finish 14. Update operation has failed [OK] !SESSION 2007-05-16 16:40:35.070 ----------------------------------------------- eclipse.buildId=I20070503-1400 java.version=1.5.0_09 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Framework arguments: -startup /home/nickb/eclipse/m7clean/eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070502.jar Command-line arguments: -os linux -ws gtk -arch x86 -startup /home/nickb/eclipse/m7clean/eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070502.jar -data /tmp/workspace-clean -consolelog !ENTRY org.eclipse.update.core 4 0 2007-05-16 16:46:14.400 !MESSAGE Error retrieving "plugins/org.eclipse.jdt.core_3.3.0.v_745.jar". [error in opening zip file] !STACK 0 java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:203) at java.util.jar.JarFile.<init>(JarFile.java:132) at java.util.jar.JarFile.<init>(JarFile.java:112) at org.eclipse.update.internal.jarprocessor.JarProcessor.processJar(JarProcessor.java:301) at org.eclipse.update.internal.core.FeaturePackagedContentProvider.retrieveLocalJar(FeaturePackagedContentProvider.java:256) at org.eclipse.update.internal.core.FeaturePackagedContentProvider.getPluginEntryArchiveReferences(FeaturePackagedContentProvider.java:179) at org.eclipse.update.internal.operations.UpdateUtils.downloadFeatureContent(UpdateUtils.java:628) at org.eclipse.update.internal.ui.wizards.InstallWizard2.download(InstallWizard2.java:426) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$3(InstallWizard2.java:397) at org.eclipse.update.internal.ui.wizards.InstallWizard2$3.run(InstallWizard2.java:350) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) !ENTRY org.eclipse.core.runtime 8 1 2007-05-16 16:46:31.893 !MESSAGE I've tried this with IBM JDK 5.0 and Sun JDK 5.0, with both staging and current Europa sites. The long timeouts are due to 404s and missing digests, I believe. Makes a helluva difference. ;-)
Created attachment 67525 [details] console logs first pass: using IBM JDK 5.0, attempt to install GMF + all dependencies (which includes PDE and JDT). second pass: try just PDE + JDT third pass: try PDE + JDT from staging site fourth pass: try PDE + JDT from staging site, with Sun JDK 5.0
(In reply to comment #0) > 12. click 'Select Required' *** WAIT up to 90 seconds if using staging site *** Correction: this took 35-45 seconds. The 90 second delay was when I tried to 'Select Required' on GMF (lots more features to process).
We don't build the jar. The same jar provided with the SDK works fine. Moving to Platform/Releng. Was the jar file properly transferred to the update site?
(In reply to comment #3) > The same jar provided with the SDK works fine. Confirmed, starting from the SDK instead of the Platform Binary works great. I have to assume the problem's with the Update site, then. If the file's there, it's corrupt (pack200 problem?). If it's missing, there's a problem in the Europa-matic files or somewhere upstream between 'build the zips' and 'build the UM site'.
This looks similar to bug 179270 which has bug 178884 as the root cause. I don't think using org.eclipse.jdt.core_3.3.0.v_745.jar is a valid test. This jar is from M6 and the jar processor issues in bug 178884 were not fixed for M6. Howerver, the org.eclipse.jdt.core_3.3.0.v_755 from M7 should not have this problem because I remember using a new update core in our builder right before we released the milestone. Apparently there is now a problem. Andrew, was a Sun and IBM JDK 5.0 tested as part of the verification for bug 178884? I know the original bug had problems with 1.6 JDKs on Linux.
Nope, it's a problem with the europa build scripts. Sorry Andrew for the false alarm. In my update site kmoir@node1:/home/data/httpd/download.eclipse.org/eclipse/updates/3.3milestones/plugins> pwd /home/data/httpd/download.eclipse.org/eclipse/updates/3.3milestones/plugins kmoir@node1:/home/data/httpd/download.eclipse.org/eclipse/updates/3.3milestones/plugins> ls -ld org.eclipse.jdt.core_3.3.0.v_755.jar* -rw-r--r-- 1 sdimitro eclipseadmin 4121211 2007-05-04 15:30 org.eclipse.jdt.core_3.3.0.v_755.jar -rw-r--r-- 1 sdimitro eclipseadmin 1459396 2007-05-04 15:30 org.eclipse.jdt.core_3.3.0.v_755.jar.pack.gz In the europa staging site kmoir@node1:/home/data/httpd/download.eclipse.org/releases/europa/staging/plugins> pwd /home/data/httpd/download.eclipse.org/releases/europa/staging/plugins kmoir@node1:/home/data/httpd/download.eclipse.org/releases/europa/staging/plugins> ls -ld org.eclipse.jdt.core_3.3.0.v_755.jar* -rw-rw-r--+ 1 bfreeman callistoadmin 4121211 2007-05-16 21:41 org.eclipse.jdt.core_3.3.0.v_755.jar -rw-rw-r--+ 1 bfreeman callistoadmin 0 2007-05-16 21:41 org.eclipse.jdt.core_3.3.0.v_755.jar.pack.gz Note that the packed jar has a size of zero on the Europa staging site. Obviously something is happening in the packing phase of the Europa build that is causing issues. Moving the cross project and cc'ing Bjorn. Bjorn, what version of the jar processor are you using in your build?
On a related note, Andrew will release this fix for RC1 Protect against JarProcessor exceptions bug 187580
(In reply to comment #6) > Nope, it's a problem with the europa build scripts. > Bjorn, what version of the jar processor are you using in your build? I am using the eclipse 3.3M7 distro and all its included jars. I just re-ran the build and am getting three zero-sized packed jars: :~/downloads/releases/europa/staging> ls -l plugins/ | grep " 0 2007" -rw-rw-r--+ 1 bfreeman callistoadmin 0 2007-05-19 18:30 org.eclipse.birt.report.engine_2.2.0.v20070518.jar.pack.gz -rw-rw-r--+ 1 bfreeman callistoadmin 0 2007-05-19 18:32 org.eclipse.jdt.core_3.3.0.v_755.jar.pack.gz -rw-rw-r--+ 1 bfreeman callistoadmin 0 2007-05-19 18:29 org.eclipse.pde.core_3.3.0.v20070501-0010.jar.pack.gz I removed all three so that the downloads and installs will work, but I'm not sure what to try next. Kim?
I forgot to put this "delete empty gz files" into the build scripts so when the build re-ran it regenerated the empty files. I have not put the delete into the Europa-matic and am re-running the build.
On 21-May-2007 morning, the bug is on the staging site again. Unfortunately, anybody starting off with the Platform and requiring EMF will fall into this due to bug #106804 not yet being complete (EMF Runtime still needs JDT). If I read Bjorn's comment right, having the zero-length files is expected ? I guess what we are waiting for now, is for Bjorn to manually fix the staging site and then promote it to release such that we can check there.
(In reply to comment #10) > If I read Bjorn's comment right, having the zero-length files is expected ? No. The zero length files are clearer a bug in the jarPackager. I can't think of case where a valid non-zero-length jar should be Pack 200'd into a zero-length file. > I guess what we are waiting for now, is for Bjorn to manually fix the staging > site and then promote it to release such that we can check there. The Europa-matic build automatically deletes zero-length files during each build now. See the "copy to staging" action in the build results (http://dash.eclipse.org/~bfreeman/europa/copy%20to%20staging-copy%20to%20staging-log.html). You should not be seeing zero-length files in the staging area at this time. (For example, as of this comment, there are no zero-length files in the staging area: /home/data/httpd/download.eclipse.org/releases/europa/staging> ls -lR | grep " 0 2007" /home/data/httpd/download.eclipse.org/releases/europa/staging> However I have experienced file caching delays in synchronizing the download servers at times. If (a) you are experiencing zero-length files from the main eclipse.org servers and (b) there is no active Europa build, then please wait 20 minutes and try again. If you're still seeing zero-length files, then there is a problem in the Europa-matic.
Bjorn, do you have the output from the packing step output to a file? For instance, we run our packing process - note the error log. <!--pack200--> <java jar="${eclipse.home}/plugins/org.eclipse.equinox.launcher.jar" fork="true" timeout="10800000" jvm="${java15-home}/bin/java" failonerror="true" maxmemory="768m" error="${buildDirectory}/errorlog.txt" dir="${buildDirectory}" output="${buildDirectory}/jarprocessorlog.txt"> <jvmarg value="-Dorg.eclipse.update.jarprocessor.pack200=${eclipse.build.configs}/../../extras" /> <arg line="-consolelog -application org.eclipse.update.core.siteOptimizer" /> <arg line="-jarProcessor -verbose -outputDir ${buildLabel} -processAll -pack ${repack} ${packtmp}/${archiveName}" /> </java> Also, how much memory are you allocating to the process - are you running out of memory? I'm moving this bug to platform update as you said it is probably an issue with the jar processor.
When I download the jars from http://download.eclipse.org/releases/europa/staging/plugins that correspond to the 0-length pack.gz files, all three of them fail to verify. Note the failures are on .class files, and therefore are unlikely to be caused by a problem in the jarProcessor. The 0-length files are likely caused by this. Are these jars the input to the Europa-matic process? If so, the sources of those jars should be checked to see if they were ok coming out of their builds, or maybe they were corrupted in a copy somehow. jarsigner -verify org.eclipse.pde.core_3.3.0.v20070501-0010.jar jarsigner: java.lang.SecurityException: SHA1 digest error for org/eclipse/pde/in ternal/core/exports/ProductExportOperation.class jarsigner -verify org.eclipse.birt.report.engine_2.2.0.v20070518.jar jarsigner: java.lang.SecurityException: SHA1 digest error for org/eclipse/birt/r eport/engine/css/engine/value/AbstractValueFactory.class jarsigner -verify org.eclipse.jdt.core_3.3.0.v_755.jar jarsigner: java.lang.SecurityException: SHA1 digest error for org/eclipse/jdt/co re/dom/Javadoc.class
(In reply to comment #13) > Are these jars the input to the Europa-matic process? Yes, they are.
(In reply to comment #12) > Bjorn, do you have the output from the packing step output to a file? The output of the pack200 command is in the Europa-matic log: http://dash.eclipse.org/~bfreeman/europa/pack200-pack200-log.html > Also, how much memory are you allocating to the process - are you running out > of memory? Here's my command line. I'm using 1Gb of memory. <java classname="org.eclipse.equinox.launcher.Main" taskname="createPack200s" fork="true" jvm="${java15-home}/bin/java" failonerror="true" resultProperty="createPack200Result" maxmemory="1024m" dir="${buildDirectory}"> <classpath> <fileset dir="${eclipse.home}/plugins"> <include name="org.eclipse.equinox.launcher_*.jar" /> </fileset> </classpath> <jvmarg value="-Dosgi.locking=none" /> <arg line="-application org.eclipse.update.core.siteOptimizer" /> <arg line="-jarProcessor -verbose -outputDir ${updateSite} -pack ${updateSite}" /> </java> This is in /cvsroot/callisto/org.eclipse.europa.tools/build-home/createPack200s.xml
New problem, probably related? See bug 188375.
Bjorn, Regarding comment #8, Are the jars correctly copied to the Europa build site before they the jar processor step runs? Looking at my update site on eclipse.org .. the pde core jar.pack.gz file your reference is there... kmoir@node1:/home/data/httpd/download.eclipse.org/eclipse/updates/3.3milestones/plugins> ls -l org.eclipse.pde.core_3.3.0.v20070501-0010.jar.pack.gz -rw-r--r-- 1 sdimitro eclipseadmin 279144 2007-05-04 15:30 org.eclipse.pde.core_3.3.0.v20070501-0010.jar.pack.gz
(In reply to comment #17) > Are the jars correctly copied to the Europa build site before they the jar > processor step runs? Kim, I'm not sure what you're asking. The Europa build loads the jar files using: [update: org.eclipse.platform] Command-line arguments: -clean -application org.eclipse.update.core.standaloneUpdate -data /home/data/users/bfreeman/europa/org.eclipse.europa.tools/build-home/buildworkspace -debug -consolelog -command mirror -featureId org.eclipse.platform -version 3.3.0.v20070516-_19REikF-XqdF6ODRccO -from http://download.eclipse.org/eclipse/updates/3.3milestones/site.xml -to /home/data/users/bfreeman/europa/staging -ignoreMissingPlugins true See http://dash.eclipse.org/~bfreeman/europa/Platform-org.eclipse.platform-log.html I assumed the org.eclipse.update.core.standaloneUpdate application copied the jar files correctly.
What I'm asking is to check for the state of the jars in the Europa build after you run org.eclipse.update.core.standaloneUpdate application to copy the jars but before you run the siteOptimizer. Do the jars referenced in comment #8 have the same size as in the local site?
(In reply to comment #19) > What I'm asking is to check for the state of the jars in the Europa build after > you run org.eclipse.update.core.standaloneUpdate application to copy the jars > but before you run the siteOptimizer. Do the jars referenced in comment #8 > have the same size as in the local site? The two jars that are ending as zero length (and thus being deleted by my build hack) at this time are: europa/staging/plugins/org.eclipse.jdt.core_3.3.0.v_763.jar.pack.gz europa/staging/plugins/org.eclipse.birt.report.engine_2.2.0.v20070518.jar.pack.gz The affected BIRT jar on the BIRT update site is: bfreeman@build:~/downloads/birt/update-site/plugins> ls -l *engine_2.2.0.v20070518* -rw-rw-r-- 1 slee common 1711313 2007-05-18 05:55 org.eclipse.birt.report.engine_2.2.0.v20070518.jar -rw-rw-r-- 1 slee common 501111 2007-05-17 17:55 org.eclipse.birt.report.engine_2.2.0.v20070518.jar.pack.gz And on the Europa build result site, after mirroring it is: bfreeman@build:~/europa/staging/plugins> !ls ls -l *engine_2.2.0.v20070518* -rw-r----- 1 bfreeman common 1711282 2007-05-28 10:02 org.eclipse.birt.report.engine_2.2.0.v20070518.jar So, no, the jars are not the same size after the org.eclipse.update.core.standaloneUpdate is run. Other jars, such as org.eclipse.birt.chart.runtime_2.2.0.v20070227.jar are exactly the same size pre- and post- standalongUpdate.
Created attachment 68972 [details] screen shot w/ UM complaining about JDT jar Starting with 3.3RC2 platform runtime binary, try to install JET and OCL + all upstream deps (including JDT). Attached image shows error.
(In reply to comment #21) see also bug 192983
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=192983 comment #7 bug 192983 really sounds like a dup of this bug
Bjorn, are the any logs associated with the operation in comment #20 Moving to update for comment, I don't know why the standalone update operation would change the jar file size.
(In reply to comment #24) Pack200 Log: http://dash.eclipse.org/~bfreeman/europa/pack200-pack200-log.html My fix Log: http://dash.eclipse.org/~bfreeman/europa/createDigests-createDigests-log.html (see the end of the page) > Moving to update for comment, I don't know why the standalone update operation > would change the jar file size. I don't either, but that's what it appears to do.
(In reply to comment #24) > I don't know why the standalone update operation > would change the jar file size. Might be completely wrong here, but I ran into a scenario recently where the code I was using to unpack and rejar existing jars as UM jars was only including FILES but not FOLDERS. I can't recall if the filesize was affected by this, however. Anyway, might be worth comparing the zip contents to see if both the before and after versions contain zipped folders as well as the files. `unzip -t`/`unzip -l` or Beyond Compare work great for this.
Bjorn, please try removing the manual copy of the jdt.core jar from the Europa build. I have just released the latest build to Europa which has a new jdt.core jar where all class files have a valid signature.
The Eclipse Update component is no longer under development, and no longer exists in the Eclipse Platform 4.x stream. If this problem still occurs in Eclipse Platform 4.2 or later, please enter a new bug report against Equinox p2.
