Hi David
You think it is rare. For OCL there were 8 JARs out of 59 that failed to
unpack/pack. Over 10% doesn't seem rare. I think that they are all
boring Java plus text/XML files. Certainly no nested JARs. The only
changes were moving from 1.6 to 1.7 on Hudson, and of course the new
certificates. I expected problems with Java 7 and pack200, so I thought
I had done a successful dry run, either at M5 or with an extra
contribution. Maybe my recollection is at fault again. But maybe it's
actually the certificates. We do as some projects do by not replacing
unchanged bundles so we have a mix of new and old certificates in the
contribution.
I'm afraid that I don't know how to selectively pack bundles so unless
there is progress in the SimRel aggregator technology or diagnosis of
the Buckminster/Hudson problems, OCL and QVTd will have to stay 100%
non-packed.
Regards
Ed Willink
On 25/03/2015 17:36, David M Williams wrote:
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
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2015.0.5856 / Virus Database: 4315/9377 - Release Date: 03/25/15
_______________________________________________
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
