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
cross-project-issues-dev@xxxxxxxxxxx
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
Version: 2015.0.5856 / Virus Database: 4315/9377 - Release Date:
03/25/15
|
