Well, we finally got a green build a few hours ago so that I was able to promote a new 'staging' repository. Those of you who are "done" should verify it is as you expect. And, still 5 hours or so to go before the deadline, so I expect things to turn our ok. As always, keep us informed of any problems.
http://download.eclipse.org/releases/staging/ reports in http://build.eclipse.org/simrel/mars/reporeports/index.html (Still a lot of legal files missing, still a lot of unsigned jars from BIRT). = = = = = = = = = Long Topic = = = = = = = = = = = Issues around "pack200": I know many of you had issues revolving around invalid jars produced by "pack200", probably related to you changing the VM you build with, to a higher version. And, I know at least some of you "turned off" packing, for your entire project build. Understandable, given the deadlines and the mysteries about why it sometimes breaks jars. (Short answer is, I think, just that there are some rare combinations of byte codes that reveal bugs in pack200, and that not much improvement has been made in pack200 for those rare combinations ... but, I do not know for sure how to tell for all cases ... it could be invalid byte codes? I could be you are "packing" something that has not been conditioned, or, conditioned with a different VM with certain parameters set. In general, "conditioning/packing" something that has already been conditioned, is not good. pre-condition --> sign --> pack200 is not the same as pre-condition --> pre-condition --> sign --> pack200 This is similar if not directly related to "signing" a jar, that has already been signed -- in theory, it can work ... but, in practice you have to do it "just right" (so, I advise not to re-sign a bundle, that has already been signed. I hope everyone, who has "turned off" packing completely will reserve some time during M7 to turn it back on for their project's build, and turn it off for only the jars that have problems. Here's a few current "statistics" that don't speak too well, of the quality of our repository, from one of the repo reports. Check of packed and not packed bundles. Mars M6 Number of jar files 5682 Number of pack.gz files 3096 Difference, number of jar files to check: 2586 Checked 2586 of 2586. Errors found: 883 Luna SR2 Number of jar files 5440 Number of pack.gz files 3372 Difference, number of jar files to check: 2068 Checked 2068 of 2068. Errors found: 467 At first I thought those numbers for Mars looked pretty bad, but then compared to Luna, and see they were not great But, even compared to "not great", the number of unpacked jars has nearly doubled in Mars M6. I am not sure (did not measure) what what translates into in terms of "extra bandwidth required" but if you haven't heard yet, our bandwidth is already pretty full -- so, please do your part to minimize that. See the report for details. http://build.eclipse.org/simrel/mars/reporeports/reports/pack200data.txt It is the "long runs" of jars from "one name space" that indicates a project has turned it off completely. And, to clarify the above statistics, not every jar has to be "packed" ... it does not help much, if the jar file does not contain Java class files, so it is the "errors" that indicate a jar file with class files, that is not packed. The others are presumably "resource only" jars (or feature.jars, which have no class files.). I hope these wordy explanation helps you understand why it is important, and how you can help keep it from getting out of control. Thanks,
_______________________________________________ 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
