Re: [cross-project-issues-dev] Neon.3 Update Problems

[Jeff Johnston <jjohnstn@xxxxxxxxxx>]

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: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-
> > issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff Johnston
> > Sent: Thursday, March 30, 2017 5:58 PM
> > To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
> > 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
> > > cross-project-issues-dev@xxxxxxxxxxx
> > > 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
> > cross-project-issues-dev@xxxxxxxxxxx
> > 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
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>