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,
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
