Re: [equinox-dev] normalized jar

[Andrew Niefer <aniefer@xxxxxxxxxx>]

I would suggest trying 3.4M7 where that
bug was first fixed, or just move up to 3.4.
Or if there are other problems upgrading,
try at least taking org.eclipse.update.core from 3.4

-Andrew

Janet Dmitrovich <jdmitrov@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

10/09/2008 05:29 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] normalized jar

The build is using eclipse-SDK-I20071127-0800-win32 (
to do the normalization and signing ) this looks to be a milestone build
of 3.4
They had some issue moving up to the 3.4 GM level.

I am using eclipes 20080617 for packing.

All of our jars contain eclipse.inf with "pack200.conditioned=true"


Janet Dmitrovich
WPLC Expeditor Software Development
jdmitrov@xxxxxxxxxx
512-838-4912 T/L:678-4912 FAX:512-838-3703
11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372)

Andrew
Niefer ---10/07/2008 05:38:19 PM---Which version of the jarprocessor are
you using?

Andrew Niefer <aniefer@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

10/07/2008 05:37 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] normalized jar

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 effort levels used on the pack step compared to the conditioning
step which might affect .class files. 

The org.eclipse.equinox.p2.jarprocessor contains a Verifier class which
will unpack pack.gz files and verify their signatures. It has a static
main method that you can run. 
If you have the conditioned jars from before packing, they should contain
an eclipse.inf file containing "pack200.conditioned=true".

Janet Dmitrovich <jdmitrov@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

10/07/2008 05:55 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] normalized jar

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 that I am using pack200 conditioned/normalized jars,
since they were built with the "-repack" option.
>> Is there some way to validate this?

>>What type if things could go wrong in the -repack/ normalization
step.

Janet Dmitrovich
WPLC Expeditor Software Development
jdmitrov@xxxxxxxxxx
512-838-4912 T/L:678-4912 FAX:512-838-3703
11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372)

Andrew
Niefer ---10/07/2008 04:24:57 PM---The contents of the jar should be bit-wise
the same, so the only difference between pre & post pack (for a previously
condition

Andrew Niefer <aniefer@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

10/07/2008 04:18 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] normalized jar

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 the entry itself. I'm not sure that these differences would amount
to a size difference for the jar. 

In the case of nested jars which are checked against their containers,
we do need the jars to be bitwise the same even in jar format. For this
reason, the jarProcessor in eclipse does an additional "normalization"
step which is different from the pack200 -repack conditioning.

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. 

-Andrew

Janet Dmitrovich <jdmitrov@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

10/07/2008 03:58 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	[equinox-dev] normalized jar

Should the size of the jar ( Normalized and signed jar ) be the same pre-packand
post-unpack ?

Janet Dmitrovich
WPLC Expeditor Software Development
jdmitrov@xxxxxxxxxx
512-838-4912 T/L:678-4912 FAX:512-838-3703
11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev