Switching to Neon.3 orbit won't solve the problem as the 3.6.8 docker-client there will still result in pulling in the newer httpclient which is also in the Neon.3 orbit repo.
I have respun the Linux Tools to create a 5.3.1 release with the updated packages. If a re-aggregation will occur and I need to change the linuxtools.b3aggrcon file for Neon maintenance, someone let me know. -- Jeff J. ----- Original Message ----- > Well, the good news is that the httpclient 4.5 bundle didn't make it into any > of the packages as far as I can see. > > I've just had a look at the latest Neon repository metadata, and there are a > lot of bundles that require a httpclient < 4.5 [1], and apparently only > Linux Tools, that (by way of the Jersey Apache Connector) requires > httpclient >= 4.5 [2]. I think the safe bet would be for Linux Tools to do a > release that uses the Neon Orbit to get rid of the newer httpclient if > that's possible. > > While in theory the two httpclient bundles should be able to work > side-by-side, we've seen a lot of wiring issues in Oxygen due to the mix - > some of which now apparently having propagated to Neon, as seen in the > thread linked to by Ed. I'm very much in doubt that even using a fixed > httpclient 4.5 bundle would solve these... > > Best, > Carsten > > [1] https://pastebin.com/Guu7G3ub > [2] https://pastebin.com/gjkGrR0g > > > -----Original Message----- > > From: [email protected] [mailto:cross-project- > > [email protected]] On Behalf Of Jeff Johnston > > Sent: Thursday, March 30, 2017 5:58 PM > > To: Cross project issues <[email protected]> > > Subject: Re: [cross-project-issues-dev] Neon.3 Update Problems > > > > Regarding the Linux Tools issue. This was due to the Oxygen M4 orbit repo > > referenced > > as part of a patch that upgraded the level of docker-client. > > > > I will cut a 5.3.1 release of Linux Tools today using the Orbit M6 repo. > > Can this be > > aggregated or used to patch the issue? > > > > -- Jeff J. > > > > ----- Original Message ----- > > > > > > > > > Hi, > > > > > > I'm concerned about the number of problems I see regarding updates to > > Neon.3. > > > For example, the missing MPC problem: > > > > > > > > https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#msg_17585 > > 38 > > > > > > It looks just like the problem we've been having with Oxygen M5/M6. That > > > problem I believe traces back to a broken version of httpclient that > > worked > > > its way into Oxygen M5: > > > > > > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=511333 > > > > > > > > > Rather than immediately fixing the problem and fixing M5, the problem > > was > > > allowed to propagate; weird and bizarre things were done to modify > > > downstream code to explicitly exclude the broken version: > > > > > > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=511406 > > > > > > Of course such upper bound constraints also explicitly exclude the new > > fixed > > > version when it came along, so now it seems M6 is also broken, because > > of > > > wiring issues: > > > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=513809 > > > > > > I think the wiring issues arose to a large extent because of the things > > done > > > during M5. In my opinion what should have happened in M5 is that the > > Orbit > > > bundle was immediately fixed (or reverted to the older version) and M5 > > was > > > respun to ensure that no broken version of httpclient ever propagated > > > further into the echo system. The last thing I would ever have expected > > (and > > > I personally would have refused to do) is for downstream clients to make > > > changes to explicitly exclude a broken version. Please let's never do > > that > > > again. And please let's never behave as if the Eclipse Platform > > project's > > > build can't be respun to fix problem. Surely we can't have a policy in > > place > > > where no matter the state of the platform's build, it must remain as is, > > > broken Orbit bundles and all. > > > > > > > > > But what seems even worse, though I don't fully understand the problem, > > is > > > how this broken orbit bundle id='org.apache.httpcomponents.httpclient' > > > version='4.5.2.v20161115-1643' got into the Neon release train > > repository. > > > Given all the problems it caused in Oxygen M5 surely we should have > > avoided > > > that at all costs. I suspect it came from this repository: > > > > > > > > > http://download.eclipse.org/linuxtools/update-neon-docker > > > > > > I say that because that repo contains the broken version of httpclient > > and > > > the versions of the docker IUs in that repo are the same as the versions > > in > > > the neon release train, so it seems to me the bundles from this repo > > were > > > aggregated into Neon. > > > > > > So now the problems we have in Oxygen M5 and M6 are also problems for > > the > > > users of Neon.3. That makes me very sad. Users expect update releases to > > be > > > stable. Surely we're doing something very wrong to get into a state > > where a > > > bundle known to be problematic nevertheless works its way into the final > > > stable update of the Neon... > > > > > > I don't know if the EGit update problems are at all related: > > > > > > > > https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#msg_17585 > > 38 > > > > > > It definitely looks like a different problem, but > > > org.slf4j.api_1.7.10.v20160921-1923 also comes from the update-neon- > > docker > > > update site. And that's not a version that's in > > > http://download.eclipse.org/tools/orbit/downloads/latest-R , i.e., it > > > appears not to be a released version. So again, one has to wonder how > > this > > > worked its way into Neon.3 causing update problems for Neon.3... > > > > > > > > > Regards, > > > Ed > > > > > > _______________________________________________ > > > cross-project-issues-dev mailing list > > > [email protected] > > > To change your delivery options, retrieve your password, or unsubscribe > > from > > > this list, visit > > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > > cross-project-issues-dev mailing list > > [email protected] > > To change your delivery options, retrieve your password, or unsubscribe > > from this list, visit > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
