Bugzilla – Full Text Bug Listing
| Summary: | packed zookeeper is no good | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> | ||||
| Component: | Cross-Project | Assignee: | Scott Lewis <slewis> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | bugs.eclipse.org, thomas, wim.jongman | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
David Williams
Adding Markus (ECF current buildmaster) and Wim (zookeeper contribution). (In reply to comment #0) > Now that's a good bugzilla summary, eh? > > But seriously, most recent aggregate runs fail with > > Unable to unpack artifact > osgi.bundle,org.eclipse.ecf.provider.zookeeper,1.0.0.v20100530-2019 in > repository file:/shared/helios/aggregation/final/aggregate: Unpacking fails > because intermediate file is empty: > /tmp/work42840/p2.optimizers.incoming42839.jar > > While I'm not sure why this specific pack.gz file is no good, but if there's no > obvious fix for that, please remove the pack.gz file from the repo (and > metadata). This has to be done too often, IMHO, that I happen to have some > sample ant script handy :) > > I had to remove one from webtools (bug 315025) and know that the platform has a > few problematic cases (bug 314603) > > <project > default="removeiu" > basedir="."> > <target > name="removeiu"> > > <property name="repoDirLocation" > value="/shared/webtools/committers/wtp-R3.2.0-S/20100529234347/S-3.2.0RC3-20100529234347/repository" > /> > > <p2.remove.iu> > <repository location="file:/${repoDirLocation}" /> > <iu id="org.eclipse.jst.jsf.facelet.core" > artifacts="(format=packed)" /> > > </p2.remove.iu> > > </target> > </project> > > > The only easy-to-fix pack200 issue I know about is that you should use Java 5, > and not Java 6 to do the pack200. This is probably/hopefully already known to Markus, but with Buckminster is there an easy way to specify using Java 5 for pack200 only? (as Java 6 is actually needed to compile the apache zookeeper lib). It's kind of annoying that Java 6 pack200 doesn't work right (but I'm sure you already have been annoyed by that David :). Thanksinadvance David...I think it's likely we'll be able to update our contribution early 6/1 pacific time, since we're coming up on Tuesday am in Europe... Given that the source must be compiled using Java 1.6, I think it will be impossible to use a Java 1.5 pack200 to pack it. The Java 1.5 pack 200 will not accept Java 1.6 binaries and even if it did, the packed file would then indicate that its content is Java 1.6. When unpacking using 1.5, you will then always get: Corrupted pack file: magic/ver = CAFED00D/160.1 should be CAFED00D/150.7 So you must either change your compiler to produce a 1.5 compatible binary or prevent that this particular jar is packed. You can do that by adding a directive to the eclipse.inf file or by adding a pack.properties file. See http://wiki.eclipse.org/JarProcessor_Options (Buckminster will honor those too). Given that ECF's platform contribution does not use pack200, I have changed the Helios contribution as well and disabled pack200 entirely. New has been kicked off https://build.ecf-project.org/hudson/job/R-HEAD-sdk.feature/53/ We will set the provider back to level 1.5. We then document to run in 1.6. I am fine with that. Alternatively we remove zookeeper support from Helios. Scott, are you fine with setting to 1.5? Just out of curiosity, what is it in zookeeper that requires use of Java 1.6? Here's a short hint that may or may not be useful. We use 1.6 for all source in Buckminster because we really like the @Override annotations on implemented interface methods. When we compile, we always compile for 1.5. You can accomplish that by having both 1.5 and 1.6 as valid EE's in the manifest (1.6 on top), regenerate the classpath, and then add the following property in your bundle build.properties file: jre.compilation.profile = J2SE-1.5 This ensures that the JDT compiler (and hence Buckminster) will produce 1.5 binaries. We bumped the version down to 1.5. Created attachment 170629 [details]
mylyn/context/zip
Just to keep people informed. We have fixed this issue and are doing an ECF build right now. As soon as completed (~1/2 hour from now) I will update the Helios contribution appropriately. Thanks all for help and patience. New ECF build and contribution to Helios completed and in place. For reference, the version is: 3.3.0.v20100601-1333 David if you would kick off an aggregation/build it would be appreciated. I'll let David resolve this bug once he has verified that the change made fixes things. Thanks to Wim and Markus for help and cooperation. Looks like it'll be an hour or two before Hudson reboots and starts a new run, so we'll see then. By convention, I like marking bugs as fixed, once it is believed they are fixed ... and don't worry, I'll re-open if if its not :) Greatest thanks. I guess long term, we'll need to run the aggregator with 1.6 (when we have bundles that really require 1.6 byte codes) but glad that is not today. |