> So things are back now that i added a dummy class to > javax.annotation.jre! I have no freaking idea why this should make a > difference but I've now at least a working build!
Not sure how much you want to pursue this, but ... a few old memories are coming back to me. First, remember that Tycho doesn't use the "batch signing service", per se, but does their own re-pack, and "pack200" ... I've always assumed they use the VM you are running your build with, but, do not know for sure. One reason they do this, is that bundles with no .class files do not profit from re-pack/pack200 (but still profit from gzip). I am not sure of the implementation details, but this includes at least features.jars and source*.jars. I am not sure if they literally "look in" other bundles to see if "resources only" (no .class files) or what. (Buckminster does something similar, but again, do not know implantation). I see your bundle has a BREE of 1.8 . Did your empty bundle also contain a BREE? Or was that added when the dummy .class added? ... wouldn't it be interesting (i.e. a "bug", sort of, in your code :) if Tycho use the presence of a BREE to decide if "class files or not"? Ok, you deserve it now, having read this far ... the old memory is ... when moving from Java 5 to Java 6, we learned that if a bundle contained .class files, at the 1.5 level, then the 1.6 pack200 tools would make one set of assumptions, so that unpacking the bundle would be compatible with either 1.5 or 1.6. BUT, if the bundle had no class files, then the pack200 tools would make another set of assumptions, and could no longer be unpacked with Java 1.5. (Yeah, silly, eh?) I've looked for the original bug, but can't find it, so might have just been a mailing list discussion? I believe the work around was just to "pack" with Java 5, even if using Java 6 to run the rest of the build. (I do not know when the infrastructure changed to use Java 6). Your case sounds similar, in some ways, though not exactly the same. Just thought you might find it comforting that similarly strange, freaky things have happened before. Old statistic of the day: By coincidence, I ran across this old bug, from way way back in "Callisto days" where I did a little analysis on "savings" (Bug 145685) and found: "It is very interesting that on a jar by jar basis, the reduced size varied everywhere from 20% to 90% of the original jar (with the 44% being a real-life-in-practice average)." I suspect we are doing even better than that now ... but hope that 44% (56% savings in bandwidth) helps explain why its important to have these pack.gz files in the first place, and, of course, they must be able to be unpacked reliably by our users, or it ends up making things worse, since then the jar has to be downloaded (too), for an overall increase in bandwidth! New tip of the day: I've not tried it yet, but I see in the pack200 spec there is a ---pass-file option, so if your "unpack200/verify" is failing due to one class, you can tell the pack200 processor to not monkey with that one class file, but still pack200 the rest. I suspect, in practice, this only effects Orbit, or others using PDE build, where they have a high degree of control over the process and parameters of pack200 (via eclipse.inf, if nothing else, which is not (fully) supported by Tycho ... but Buckminster does, I believe support that part of eclipse.inf files. [And to be clear, I am not suggesting everyone "jump through hoops" here ... I personally was worried about one case, ICU4J, which is a huge jar file, and seemed to be having trouble being packed by Java 8, due to one class, but, like I said, I have not tried it yet to see if it solves the problem. Tracking in Bug 464100 if anyone is that interested.]. Thanks for reading a yet another long and extra wordy note!
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
