[cross-project-issues-dev] A funny thing happened on the way to Mars.2 -

["David M Williams" <david_williams@xxxxxxxxxx>]

I just wanted to call everyone's attention
to Orbit Bug 487833.

This  will only be relevant to
you if you use 
org.apache.httpcomponents.httpclient
and exactly version
4.3.6.v201411290715

It turns out there are two version of
that bundle, with same version and qualifier. The only difference is that
one is correctly signed, and the other is not correctly signed. 

One that is not correctly signed is in two Orbit R-repositories:

 R20151221205849  Mars.2
 R20151118145958  Mars.1 Patches 

By lucky coincidence, the one that is in the Sim. Release
repos is the correctly signed one (including Mars.2 Sim. Release "maintenance"
(staging) repository). 

Therefore I am NOT suggesting we "re-spin" Mars.2.
 But, I am proposing that right after Mars.2, Orbit will declare another
R-build that is exactly the same as the Mars.2 repo, but with that bundle
correctly signed. It will have version 4.3.6.v201411290715B
 (the 'B' making it "higher" than the sometimes-incorrectly-signed
one). 

I thought I would mention this now for two reasons: 
A. If anyone has a concrete reason how this plan would
cause problems, let us know by commenting in Bug 487833.
And, 
B. If anyone has this bundle/version your own "project
repositories" it would be a good time for you verify it is OK, and
if not, to decide what to do. 
It is easy to check. From the plugins directory of your
repository, run 
jarsigner -verify  org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar

I am hoping no one else has the issue because for years
 we in the Eclipse Platform get this bundle from ECF so it is pretty
much "everywhere" already. 

The problem in Orbit was introduced some time towards
the end of last year.  It was probably caused in part by some error
I made when making an Orbit build change, or making that "Patch Build"?

But another reason for the problem is that a infrastructure's
signing service does not always work as expect. Sometimes "skipping"
a jar that is already signed, but sometimes re-signing it again with Java
6.  The reason I am guessing that is due to Bug 487087,
where ECF is having trouble getting that bundle "returned" from
signing service correctly (that is, correctly untouched).  Any Buckminster
Build experts reading this that know how to set an environment variable
to force Java 8 to be used during signing could probably solve that bug
for ECF. 

Thanks all,