Hi
You explain why relatively few projects shared the pain at M6;
Maven/Tycho was insulated.
The easiest way to test is to run the aggregator build and note down
all the
[exec] - mirroring artifact
osgi.bundle,org.eclipse.m2m.qvt.oml,3.5.0.v20150324-1623
[exec] doing copy of optimized artifact
[exec] unpacking optimized artifact
[exec] Unable to unpack artifact
osgi.bundle,org.eclipse.m2m.qvt.oml,3.5.0.v20150324-1623 in
repository file:/shared/simrel/mars/aggregation/final/aggregate:
Invalid
content:org/eclipse/m2m/internal/qvt/oml/stdlib/model/StdlibFactory.class
errors that are in your contribution. Just put a
META-INF/eclipse.inf containing
jarprocessor.exclude.pack=true
in each of them rebuild, recontribute and you're done.
If you want to be a bit more sociable you can check each of your
*.pack.gz files before contributing by
unpack200 xxx.pack.gz xxx.jar
jarsigner -verify xxx.jar
Bad files report a SHA1 digest failure.
Regards
Ed Willink
On 11/04/2015 08:58, Alexander Nyßen
wrote:
David,
I admit I am not very acquainted with the internals
of signing and pack200. However, we are using Tycho for our
builds, but our jobs provide the following option when calling
Maven (which seems to be used by a couple of other hudson jobs
as well; it was probably recommended in some instructions I
don’t remember):
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Xmx768m
I assume we will have to adopt this to something
like the following then, right:
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/jdk1.8.0_x86-latest/jre/bin“
Is there a way to confirm that a build behaves as
expected (do the sim-rel repo-reports for instance cover this)?
Cheers
Alexander
I
wanted to let everyone know that "we"
are changing the version of Java's pack200 at the
infrastructure service
I call "batch signer". (Bug 463510)
It was using Java 6 level of
pack200, and we have moved
to the Java 8 level of pack200.
This command
is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29
This does not
directly impact Tycho
users or Buckminster users (which do their own re-pack
and pack, based
on the VM the build is running, I assume) but might
effect PDE users, which
traditionally have used this service to "re-pack"
(condition)
and sign jars -- and, then at some short later time
are "packed".
At that "some later time", it is the release
engineers
responsibility to use the same version to 'pack' as
was used to 'repack'.
While no
direct impact to Tycho or Buckminster
builders, the principles and consequences of moving
from one level (Java
6) to another (Java 8) apply with any builder, so the
following points
may be useful information to all.
If you have
"old byte codes",
or, even new ones, compiled at the Java 4, Java 5, or
Java 6 level, you
*might* find some of those bytes codes no longer
survive the "re-pack",
sign, and "pack" process (where as maybe the would
survived,
when using Java 6 to run your build (and hence your
repack/pack). That
is, if user tries to download the pack.gz file, and
unpack into a normal
jar, it may be reported to have in "invalid signature"
or in
some other way "broken".
In my
experience, with Orbit jars, the
"error rate" is about 1.7%. Others, for some unknown
reason,
see higher rates (such as 20-30%?) . Some of these
cases *might* be bugs
in the pack/unpack programs, but it's just as likely
that there are "bugs"
(fringe cases) where the byte codes for lower levels
of Java are not quite
"right". All I know for sure: it has never been
perfect.
But, luckily,
easy to solve.
All three
builders (PDE, Tycho, and
Buckminster) allow you to specify an 'eclipse.inf'
file in the META-INF
directory, with a directive (line) that is:
jarprocessor.exclude.pack=true
Thus, that one
problematic jar is not
packed, but is still signed.
So important
point 1: be sure you "pack200"
with the same version you used to do "repack" (if the
builder
doesn't do it for you automatically).
Important
point 2: I wouldn't recommend
studying the byte codes and trying to find a pattern
of code that is the
cause (unless you just happen to love byte codes), ...
just slap in an
eclipse.inf file and move on to more important things.
Important
point 3: You should not, ever
never, "re-sign" and certainly not re-pack or pack200
a jar that
has already been signed or processed by pack200. That
pretty much guarantees
the jar will be broken. In more ways than one. (Bug 461669)
The reason for
making this move, now,
is that it is best to "keep up" with what our users
are using,
and, with versions of Java that are expected to stay
in service for a while
... otherwise, we might have to monkey around with
this during a service
release, which is less than ideal.
* Bonus, for
reading this far in my
wordy note: Why jump two levels, from 6 to 8, why not
move to Java 7 first?
Well it turns out, at the moment, the versions of
pack200 and unpack200
that ship with Java 7 and Java 8 are exactly
the same. But, the advantage is,
in some service release, there might be a new version
and we'd pick it
up automatically, as long as we use /shared/common/jdk1.8.0_x86-latest
consistently. Double bonus: remember that pack200 and
unpack200 have
little to do with Java source code they are
stand-alone executables, written
in C-code, that simply manipulate byte codes. Which is
how p2 can let you
specify
any version of pack200 you want,
no mater which version of Java you are using.
Naturally,
feel free to comment in Bug 463510
if any
questions or concrete problems
known.
_______________________________________________
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
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr.
Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael
Neuhaus, Jennifer Fiorentino
_______________________________________________
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.5863 / Virus Database: 4328/9508 - Release Date: 04/11/15
|
