[tycho-user] compare-version-with-baselines on signed jar

[Julien DEHAUDT]

Dear all,

I've followed https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers combined with the compare-version-with-baselines plugin.

All works like a charm with unsigned plugins but troubles come as soon as I try to sign plugins:
[ERROR] Baseline and reactor have same fully qualified version, but with different content

Reproduced on versions 1.0.0 and 1.1.0-SNAPSHOT.

Here is what I did:

1) Start a signed build with empty baseline

2) Copied built repository into baseline

3) Start a signed build again

Diff also reports that jar files differ but content is strictly similar.
Looks like the plugin does not support comparisons for signed plugins.

Thanks by advance for the help.

Cheers,
Julien

[Julien DEHAUDT]

Well, after browsing Buzgilla, Gerrit and Git I saw a recent changes made by Mickael Istria on an equivalent topic:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=479875

I came to the deduction that adding the following parameter to the plugin configuration should work with 1.1.0-SNAPSHOT:
<comparator>zip</comparator>

It works fine !
But I'm not sure to fully control the scope of such configuration in terms of valid comparison of signed baseline vs. signed build ?

Julien

From: Julien DEHAUDT
Sent: vendredi 6 octobre 2017 15:58
To: tycho-***@eclipse.org
Subject: compare-version-with-baselines on signed jar

Dear all,

I've followed https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers combined with the compare-version-with-baselines plugin.

All works like a charm with unsigned plugins but troubles come as soon as I try to sign plugins:
[ERROR] Baseline and reactor have same fully qualified version, but with different content

Reproduced on versions 1.0.0 and 1.1.0-SNAPSHOT.

Here is what I did:

1) Start a signed build with empty baseline

2) Copied built repository into baseline

3) Start a signed build again

Diff also reports that jar files differ but content is strictly similar.
Looks like the plugin does not support comparisons for signed plugins.

Thanks by advance for the help.

Cheers,
Julien

[Mickael Istria]

Hi,

In general, it's better if you can fully reproduce the build, byte to byte.
And by default, compare-version-with-baselines assumes that you want a
byte-to-byte equality, which is the ultimate form of build reproducibility.
However, in practice, it's pretty possible that the 2 jars have the exact
same payload and can be treated as equivalent. Using the Zip comparator as
you did allows to compare jar *equivalency* rather than equality. In most
case, it's enough. It's for example what Eclipse Platform is using.
For your case, if you know your bundle are equal (made from the same
commit), you could consider as an addition to set up Reproducible Version
Qualifiers as explained in
https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers#What_does_this_actually_do.3F
. That would allow, in case of equivalent bundles, to have the build use
the baseline one, so it usually turns the equivalency into an equality, and
the following compare-version-with-baselines works fine.
But it's not bullet proof, especially with pack200. If you pack200 your
jars, it's possible that even an unpack200'd jar is not equal to the same
jar that was pack200'd earlier... That can become tricky and I think
pack200 has ways to workaround that; however it's not a topic I know enough
to help you with.

HTH

[Matthew Piggott]

I have a memory that Eclipse platform used to pack -> unpack to normalize
jars before distribution.

Post by Mickael Istria
Hi,
In general, it's better if you can fully reproduce the build, byte to
byte. And by default, compare-version-with-baselines assumes that you want
a byte-to-byte equality, which is the ultimate form of build
reproducibility.
However, in practice, it's pretty possible that the 2 jars have the exact
same payload and can be treated as equivalent. Using the Zip comparator as
you did allows to compare jar *equivalency* rather than equality. In most
case, it's enough. It's for example what Eclipse Platform is using.
For your case, if you know your bundle are equal (made from the same
commit), you could consider as an addition to set up Reproducible Version
Qualifiers as explained in https://wiki.eclipse.org/
Tycho/Reproducible_Version_Qualifiers#What_does_this_actually_do.3F .
That would allow, in case of equivalent bundles, to have the build use the
baseline one, so it usually turns the equivalency into an equality, and the
following compare-version-with-baselines works fine.
But it's not bullet proof, especially with pack200. If you pack200 your
jars, it's possible that even an unpack200'd jar is not equal to the same
jar that was pack200'd earlier... That can become tricky and I think
pack200 has ways to workaround that; however it's not a topic I know enough
to help you with.
HTH
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user

[Mickael Istria]

Post by Matthew Piggott
I have a memory that Eclipse platform used to pack -> unpack to normalize
jars before distribution.

Right, it does run the normalize step first. However, there is still
something in Platform that cause jars to be unequal although they're
equivalent, or even to make them as not equivalent although they are. I'm
currently accusing pack200 as the usual suspect, but it could be something
else.
If you want to join the fun of this investigation,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=525601 is a good entry point.

Cheers,