By lucky coincidence, the one that is in the Sim. Release
repos is the correctly signed one (including Mars.2 Sim. Release "maintenance"
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
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