Sorry I was slow on this,
1 - JDK 1.5 pack can handle 1.6 (or
later) java code, the things that it doesn't understand as essentially
2 - If JDK 1.6 is used to pack, then
this is not necessarily unpackable by a 1.5 JDK. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=211613
3 - There was no pack200 support in
1.4.2, so a 1.5 JDK is required as a minimum to unpack. Any higher
version should also work, service releases are expected to be compatible.
4 - yes, different jars could be packed
by different pack200 versions if they were produced by different builds
The pack200 parameters that were used
to condition/pack a bundle are recorded in that bundle's META-INF/eclipse.inf
file. These aren't needed for unpacking, but rather on the repacking.
Running pack -> unpack changes a jar, so when we are signing we
need to first "condition" or normallize the jar : pack ->
unpack -> sign -> pack. This is where the parameters are important,
the 2nd pack should use the same parameters as the first pack. This
is all on the producer side and the consumer doesn't care.
There are some docs on this file in
the wiki http://wiki.eclipse.org/JarProcessor_Options.
This file is also as input to the jarprocessor
to control packing/signing of that bundle.
The only thing I think we might be missing
would be to record in the artifact.xml the compatibility level of the pack.gz
file so that we could avoid downloading it if we don't think we will be
able to unpack it. Doing this would require the jarprocessor tool
to be p2 aware, and smarter than it currently is. This seems to be too
large a change for 3.5.
For whatever reasons, I have always
treated the unpacking of pack.gz files as something that can fail, and
we need to be able to fall back to just downloading the normal jar.
Henrich Kraemer <henrich.kraemer@xxxxxxxxxx> Sent by: p2-dev-bounces@xxxxxxxxxxx
03/30/2009 06:51 PM
Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>
[p2-dev] pack200, JRE versions requirements
I am looking into potential issues using (and creating)
pack 200 jars (artifacts).
I believe that packing code for a particular JRE version (as per.class
files compatibility) requires pack200 and unpack200 from at least that
JRE version. https://bugs.eclipse.org/bugs/show_bug.cgi?id=141195#c3
suggests that there may be a dependency on the particular parameters used
in pack200 as well.
What is the latest on this?
Also does unpack200 must be of the same or higher JRE version as the pack200
used during packing? For example if the jar processing was done with JDK
1.5 is the unpacker required to be from the 1.5 version? If so is any JRE
service release (expected to be compatible)?
Are there other potential pitfalls to watch out for?
For the each pluging which will be produced for the 3.5 update site how
is the following specified:
- the jre version to use
- pack 200 parameters
- whether it should be packed at all.
Will different jars be packed with different pack200 versions?
p2-dev mailing list