Thanks Tom -
I'll open bug.
Can anyone verify that this command line is correct
- java jar:=${equinox.launcher} fork=true jvm=$
{java.home}/bin/java.exe failonerror=true maxmemory=512m dir=
@{sign.dir} output=${log.dir}/sign.log append=true
arg value=-application /
Should the size of the jar ( Normalized and signed jar ) be the same
pre-packand post-unpack ?
Janet Dmitrovich
WPLC Expeditor Software Development
[EMAIL PROTECTED]
512-838-4912 T/L:678-4912 FAX:512-838-3703
11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372)
The contents of the jar should be bit-wise the same, so the only
difference between pre post pack (for a previously conditioned jar), if
any, would be in the format of the jar itself. Differences could be, for
example, in size crc information for a given zip entry appearing before
or after
Hi thanks for the reply Andrew.
If you are getting differences after unpack, you may not actually be using
pack200 conditioned/normalized jars, or something went wrong in that
-repack normalization step.
So I am finding differences in the jar sizes ( pre and post pack )
I'm fairly certain
Which version of the jarprocessor are you using?
There was a bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=226850)
fixed in 3.4. This was leading to verification errors on the
META-INF/eclipse.inf files. Though if I remember correctly, it could have
potentially led to different pack