Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Frederic Gurr]

;> org.apache.httpcomponents.httpcore
> >>>>>   4.3.3.v201411290715
> >>>>>   4.2.5.v201311072007
> >>>>>
> >>>>>
> >>>>> So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore
> version 4.4.6 are
> >>>>> not in the repo any more.
> >>>>>
> >>>>> @All: Can someone confirm that this fixes the update
> problem (earlier
> >>>>> version to Neon.3)?
> >>>>>
> >>>>> If it is confirmed to work, we have a fix for users that
> have not
> >>>>> upgraded to Neon.3 yet. Users that already upgraded are
> unaffected by
> >>>>> this. They still need to wait for a "wiring issue" fix.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Fred
> >>>>>
> >>>>>
> >>>>> On 21.04.2017 23:00, Jeff Johnston wrote:
> >>>>>> Just to confirm that the change has been merged to the
> Neon.3_respin
> >>>>>> branch.
> >>>>>>
> >>>>>> -- Jeff J.
> >>>>>>
> >>>>>> On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston
> <jjohn...@redhat.com <mailto:jjohn...@redhat.com>
> >>>>>> <mailto:jjohn...@redhat.com
> <mailto:jjohn...@redhat.com>>> wrote:
> >>>>>>
> >>>>>>I have done another respin.  In this case, I
> rebuilt the Linux
> >>>>>> Tools
> >>>>>>plug-ins to use the older version
> >>>>>>of docker-client and its dependencies which were
> used in
> >>>>>> Neon.2.  I
> >>>>>>have back-versioned the
> >>>>>>Docker tooling plug-ins to 2.3.0 with the current
> date.
> >>>>>>
> >>>>>>I have just pushed to gerrit for Neon.3_respin branch.
> >>>>>>
> >>>>>>https://git.eclipse.org/r/#/c/95501/
> <https://git.eclipse.org/r/#/c/95501/>
> >>>>>><https://git.eclipse.org/r/#/c/95501/
> <https://git.eclipse.org/r/#/c/95501/>>
> >>>>>>
> >>>>>>If no-one objects, I will merge into the branch.
> >>>>>> Verification is
> >>>>>>    already successful.
> >>>>>>
>     >>>>>>-- Jeff J.
> >>>>>>
> >>>>>>On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston
> >>>>>> <jjohn...@redhat.com <mailto:jjohn...@redhat.com>
> >>>>>><mailto:jjohn...@redhat.com
> <mailto:jjohn...@redhat.com>>> wrote:
> >>>>>>
> >>>>>>Marcel,
> >>>>>>
> >>>>>>Since the respin didn't fix the problem, we
> will try
> >>>>>> reverting
> >>>>>>the docker-client dependency and keeping as
> much of the
> >>>>>> added
> >>>>>>Neon.3 functionality as possible
> >>>>>>in place and cutting another point release.  I
> will let the
> >>>>>> list
> >>>>>>know when I have something in place.
> >>>>>>
> >>>>>>-- Jeff J.
> >>>>>>
> >>>>>>On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
> >>>>>><daniel_meg...@ch.ibm.com
> <mailto:daniel_meg...@ch.ibm.com> <mailto:daniel_meg...@ch.ibm.com
> <mailto:daniel_meg...@ch.ibm.com>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>Adding
> eclipse.org-pl

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Jeff Johnston]

regation/final
>>>>> so I think this is a good demonstration that installations creation
>>>>> from
>>>>> this repository's contents will not have the wiring problems we've been
>>>>> seeing in Neon.3.
>>>>>
>>>>> Regards,
>>>>> Ed
>>>>>
>>>>>
>>>>> Ed,
>>>>>>
>>>>>> The temporary update site URL is:
>>>>>>
>>>>>> https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.r
>>>>>> unaggregator.BUILD__CLEAN/3/artifact/aggregation/final
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Fred
>>>>>>
>>>>>> On 25.04.2017 15:13, Ed Merks wrote:
>>>>>>
>>>>>>> Fred,
>>>>>>>
>>>>>>> What update site URL contains these results?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Ed
>>>>>>>
>>>>>>>
>>>>>>> On 25.04.2017 14:28, Frederic Gurr wrote:
>>>>>>>
>>>>>>>> Thanks Jeff,
>>>>>>>>
>>>>>>>> This is the comparison of the non-unique versions list:
>>>>>>>>
>>>>>>>> neon3_respin aggregation build 20.04.
>>>>>>>> (https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.
>>>>>>>> runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buil
>>>>>>>> dInfo/reporeports/reports/nonUniqueVersions.txt):
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> org.apache.httpcomponents.httpclient
>>>>>>>>   4.3.6.v201411290715
>>>>>>>>   4.5.2.v20161115-1643
>>>>>>>>   4.3.6.v201511171540
>>>>>>>>   4.2.6.v201311072007
>>>>>>>> org.apache.httpcomponents.httpcore
>>>>>>>>   4.3.3.v201411290715
>>>>>>>>   4.4.6.v20170210-0925
>>>>>>>>   4.2.5.v201311072007
>>>>>>>>   neon3_respin aggregation build 25.04.
>>>>>>>> (https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.
>>>>>>>> runaggregator.BUILD__CLEAN/3/artifact/aggregation/final/buil
>>>>>>>> dInfo/reporeports/reports/nonUniqueVersions.txt):
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> org.apache.httpcomponents.httpclient
>>>>>>>>   4.3.6.v201411290715
>>>>>>>>   4.3.6.v201511171540
>>>>>>>>   4.2.6.v201311072007
>>>>>>>> org.apache.httpcomponents.httpcore
>>>>>>>>   4.3.3.v201411290715
>>>>>>>>   4.2.5.v201311072007
>>>>>>>>
>>>>>>>>
>>>>>>>> So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6
>>>>>>>> are
>>>>>>>> not in the repo any more.
>>>>>>>>
>>>>>>>> @All: Can someone confirm that this fixes the update problem
>>>>>>>> (earlier
>>>>>>>> version to Neon.3)?
>>>>>>>>
>>>>>>>> If it is confirmed to work, we have a fix for users that have not
>>>>>>>> upgraded to Neon.3 yet. Users that already upgraded are unaffected
>>>>>>>> by
>>>>>>>> this. They still need to wait for a "wiring issue" fix.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Fred
>>>>>>>>
>>>>>>>>
>>>>>>>> On 21.04.2017 23:00, Jeff Johnston wrote:
>>>>>>>>
>>>>>>>>> Just to confirm that the change has been merged to the
>>>>>>>>> Neon.3_respin
>>>>>>>>> branch.
>>>>>>>>>
>>>>>>>>> -- Jeff J.
>>>>>>>>>
>>>>>>>>> On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <
>>>>>>>>> jjohn.

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Oberhuber, Martin]

se.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):
>>>>>
>>>>>
>>>>>
>>>>> org.apache.httpcomponents.httpclient
>>>>>   4.3.6.v201411290715
>>>>>   4.5.2.v20161115-1643
>>>>>   4.3.6.v201511171540
>>>>>   4.2.6.v201311072007
>>>>> org.apache.httpcomponents.httpcore
>>>>>   4.3.3.v201411290715
>>>>>   4.4.6.v20170210-0925
>>>>>   4.2.5.v201311072007
>>>>>   neon3_respin aggregation build 25.04.
>>>>> 
(https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):
>>>>>
>>>>>
>>>>>
>>>>> org.apache.httpcomponents.httpclient
>>>>>   4.3.6.v201411290715
>>>>>   4.3.6.v201511171540
>>>>>   4.2.6.v201311072007
>>>>> org.apache.httpcomponents.httpcore
>>>>>   4.3.3.v201411290715
>>>>>   4.2.5.v201311072007
>>>>>
>>>>>
>>>>> So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6 are
>>>>> not in the repo any more.
>>>>>
>>>>> @All: Can someone confirm that this fixes the update problem (earlier
>>>>> version to Neon.3)?
>>>>>
>>>>> If it is confirmed to work, we have a fix for users that have not
>>>>> upgraded to Neon.3 yet. Users that already upgraded are unaffected by
>>>>> this. They still need to wait for a "wiring issue" fix.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Fred
>>>>>
>>>>>
>>>>> On 21.04.2017 23:00, Jeff Johnston wrote:
>>>>>> Just to confirm that the change has been merged to the Neon.3_respin
>>>>>> branch.
>>>>>>
>>>>>> -- Jeff J.
>>>>>>
>>>>>> On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com
>>>>>> <mailto:jjohn...@redhat.com>> wrote:
>>>>>>
>>>>>>I have done another respin.  In this case, I rebuilt the Linux
>>>>>> Tools
>>>>>>plug-ins to use the older version
>>>>>>of docker-client and its dependencies which were used in
>>>>>> Neon.2.  I
>>>>>>have back-versioned the
>>>>>>Docker tooling plug-ins to 2.3.0 with the current date.
>>>>>>
>>>>>>I have just pushed to gerrit for Neon.3_respin branch.
>>>>>>
>>>>>>https://git.eclipse.org/r/#/c/95501/
>>>>>><https://git.eclipse.org/r/#/c/95501/>
>>>>>>
>>>>>>If no-one objects, I will merge into the branch.
>>>>>> Verification is
>>>>>>already successful.
>>>>>>
>>>>>>    -- Jeff J.
    >>>>>>
    >>>>>>    On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston
>>>>>> <jjohn...@redhat.com
>>>>>><mailto:jjohn...@redhat.com>> wrote:
>>>>>>
>>>>>>Marcel,
>>>>>>
>>>>>>Since the respin didn't fix the problem, we will try
>>>>>> reverting
>>>>>>the docker-client dependency and keeping as much of the
>>>>>> added
>>>>>>Neon.3 functionality as possible
>>>>>>in place and cutting another point release.  I will let 
the
>>>>>> list
>>>>>>know when I have something in place.
>>>>>>
>>>>>>-- Jeff J.
>>>>>>
>>>>>>On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
>>>>>> 

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Jeff Johnston]

gt;>>
>>>>>>
>>>>>> On 25.04.2017 14:28, Frederic Gurr wrote:
>>>>>>
>>>>>>> Thanks Jeff,
>>>>>>>
>>>>>>> This is the comparison of the non-unique versions list:
>>>>>>>
>>>>>>> neon3_respin aggregation build 20.04.
>>>>>>> (https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.
>>>>>>> runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buil
>>>>>>> dInfo/reporeports/reports/nonUniqueVersions.txt):
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> org.apache.httpcomponents.httpclient
>>>>>>>   4.3.6.v201411290715
>>>>>>>   4.5.2.v20161115-1643
>>>>>>>   4.3.6.v201511171540
>>>>>>>   4.2.6.v201311072007
>>>>>>> org.apache.httpcomponents.httpcore
>>>>>>>   4.3.3.v201411290715
>>>>>>>   4.4.6.v20170210-0925
>>>>>>>   4.2.5.v201311072007
>>>>>>>   neon3_respin aggregation build 25.04.
>>>>>>> (https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.
>>>>>>> runaggregator.BUILD__CLEAN/3/artifact/aggregation/final/buil
>>>>>>> dInfo/reporeports/reports/nonUniqueVersions.txt):
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> org.apache.httpcomponents.httpclient
>>>>>>>   4.3.6.v201411290715
>>>>>>>   4.3.6.v201511171540
>>>>>>>   4.2.6.v201311072007
>>>>>>> org.apache.httpcomponents.httpcore
>>>>>>>   4.3.3.v201411290715
>>>>>>>   4.2.5.v201311072007
>>>>>>>
>>>>>>>
>>>>>>> So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6
>>>>>>> are
>>>>>>> not in the repo any more.
>>>>>>>
>>>>>>> @All: Can someone confirm that this fixes the update problem (earlier
>>>>>>> version to Neon.3)?
>>>>>>>
>>>>>>> If it is confirmed to work, we have a fix for users that have not
>>>>>>> upgraded to Neon.3 yet. Users that already upgraded are unaffected by
>>>>>>> this. They still need to wait for a "wiring issue" fix.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Fred
>>>>>>>
>>>>>>>
>>>>>>> On 21.04.2017 23:00, Jeff Johnston wrote:
>>>>>>>
>>>>>>>> Just to confirm that the change has been merged to the Neon.3_respin
>>>>>>>> branch.
>>>>>>>>
>>>>>>>> -- Jeff J.
>>>>>>>>
>>>>>>>> On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com
>>>>>>>> <mailto:jjohn...@redhat.com>> wrote:
>>>>>>>>
>>>>>>>>I have done another respin.  In this case, I rebuilt the
>>>>>>>> Linux
>>>>>>>> Tools
>>>>>>>>plug-ins to use the older version
>>>>>>>>of docker-client and its dependencies which were used in
>>>>>>>> Neon.2.  I
>>>>>>>>have back-versioned the
>>>>>>>>Docker tooling plug-ins to 2.3.0 with the current date.
>>>>>>>>
>>>>>>>>I have just pushed to gerrit for Neon.3_respin branch.
>>>>>>>>
>>>>>>>>https://git.eclipse.org/r/#/c/95501/
>>>>>>>><https://git.eclipse.org/r/#/c/95501/>
>>>>>>>>
>>>>>>>>If no-one objects, I will merge into the branch.
>>>>>>>> Verification is
>>>>>>>>already successful.
>>>>>>>>
>>>>>>>>-- Jeff J.
>>>>>>>>
>>>>>>>>On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston
>>>>>>>> <jjohn...@redhat.com
>>>>>>>><mailto:jjohn...@redhat.com>>

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Jeff Johnston]

al/
>>>>>> buildInfo/reporeports/reports/nonUniqueVersions.txt):
>>>>>>
>>>>>>
>>>>>>
>>>>>> org.apache.httpcomponents.httpclient
>>>>>>   4.3.6.v201411290715
>>>>>>   4.3.6.v201511171540
>>>>>>   4.2.6.v201311072007
>>>>>> org.apache.httpcomponents.httpcore
>>>>>>   4.3.3.v201411290715
>>>>>>   4.2.5.v201311072007
>>>>>>
>>>>>>
>>>>>> So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6 are
>>>>>> not in the repo any more.
>>>>>>
>>>>>> @All: Can someone confirm that this fixes the update problem (earlier
>>>>>> version to Neon.3)?
>>>>>>
>>>>>> If it is confirmed to work, we have a fix for users that have not
>>>>>> upgraded to Neon.3 yet. Users that already upgraded are unaffected by
>>>>>> this. They still need to wait for a "wiring issue" fix.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Fred
>>>>>>
>>>>>>
>>>>>> On 21.04.2017 23:00, Jeff Johnston wrote:
>>>>>>
>>>>>>> Just to confirm that the change has been merged to the Neon.3_respin
>>>>>>> branch.
>>>>>>>
>>>>>>> -- Jeff J.
>>>>>>>
>>>>>>> On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com
>>>>>>> <mailto:jjohn...@redhat.com>> wrote:
>>>>>>>
>>>>>>>I have done another respin.  In this case, I rebuilt the Linux
>>>>>>> Tools
>>>>>>>plug-ins to use the older version
>>>>>>>of docker-client and its dependencies which were used in
>>>>>>> Neon.2.  I
>>>>>>>have back-versioned the
>>>>>>>    Docker tooling plug-ins to 2.3.0 with the current date.
>>>>>>>
>>>>>>>I have just pushed to gerrit for Neon.3_respin branch.
>>>>>>>
>>>>>>>https://git.eclipse.org/r/#/c/95501/
>>>>>>><https://git.eclipse.org/r/#/c/95501/>
>>>>>>>
>>>>>>>If no-one objects, I will merge into the branch.
>>>>>>> Verification is
>>>>>>>already successful.
>>>>>>>
>>>>>>>-- Jeff J.
>>>>>>>
>>>>>>>On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston
>>>>>>> <jjohn...@redhat.com
>>>>>>><mailto:jjohn...@redhat.com>> wrote:
>>>>>>>
>>>>>>>Marcel,
>>>>>>>
>>>>>>>Since the respin didn't fix the problem, we will try
>>>>>>> reverting
>>>>>>>the docker-client dependency and keeping as much of the
>>>>>>> added
>>>>>>>Neon.3 functionality as possible
>>>>>>>in place and cutting another point release.  I will let
>>>>>>> the
>>>>>>> list
>>>>>>>know when I have something in place.
>>>>>>>
>>>>>>>-- Jeff J.
>>>>>>>
>>>>>>>On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
>>>>>>><daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.c
>>>>>>> om>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>Adding eclipse.org-planning-coun...@eclipse.org
>>>>>>><mailto:eclipse.org-planning-coun...@eclipse.org> to
>>>>>>> this
>>>>>>>thread.
>>>>>>>
>>>>>>>Dani
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>From:"Dr. Marcel Bruch"
>>>>>>> <marcel.br...@codetrails.com
>>>>>>><mailto:marcel.br...@codetrai

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Ed Merks]

7 at 6:38 AM, Daniel Megert
   <daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.com>>
wrote:

   Adding eclipse.org-planning-coun...@eclipse.org
   <mailto:eclipse.org-planning-coun...@eclipse.org> to
this
   thread.

   Dani



   From:"Dr. Marcel Bruch"
<marcel.br...@codetrails.com
   <mailto:marcel.br...@codetrails.com>>
   To:Cross project issues
   <cross-project-issues-dev@eclipse.org
   <mailto:cross-project-issues-dev@eclipse.org>>
           Date:21.04.2017 10:17
       Subject:Re: [cross-project-issues-dev] Neon.3
Update
   Problems: To Fix andHow to Fix?
   Sent by:
cross-project-issues-dev-boun...@eclipse.org
   <mailto:cross-project-issues-dev-boun...@eclipse.org>
 






   Hi,

   I’ll briefly summarize the discussion we had at the AC
   yesterday:

   Given that we don’t know how the OSGI resolver will
behave
   (even after Tom back-ported a fix to Neon) it would be
   preferred to just have the Apache HTTP*** versions in
Neon.3
   that were already in Neon.2. This would to some extend
   “ensure" that we are "at least as as stable as Neon.2”.
This
   would require us to rollback the changes that introduced
the
   latest version of HTTPClient. As far as I know this
would
   especially affect the Docker Tooling. (maybe more
changes
   than that are needed)

   My question to the *Docker Tooling project lead*: Is it
   possible to rollback this last minute change and
postpone it
   to Oxygen for the sake of making EGit, MPC, Oomph,
USS, and
   Code Recommenders work reliably again - and giving us
more
   trust that we won’t get into trouble with Neon.3? The
   simplest solution may be to contribute the docker
tooling
   from Neon.2 in Neon.3. WDYT?

   Marcel




   On 20 Apr 2017, at 18:54, Frederic Gurr
   <_frederic.gurr@eclipse.org_
   <mailto:frederic.g...@eclipse.org>> wrote:

   I can see
 
org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in
 
/home/data/httpd/_download.eclipse.org/linuxtools/update-docker-2.3.1/plugins_



 
<http://download.eclipse.org/linuxtools/update-docker-2.3.1/plugins>,

   but it's definitely not in the aggregated repo.


   On 20.04.2017 18:31, Jeff Johnston wrote:
   Fred,

   The version of httpclient also changed in our
   update-docker-2.3.1 repo from:

  
org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643


   to:

  
org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925


   Not sure why this change isn't being seen as well.

   -- Jeff J.



   On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr
   <_frederic.gurr@eclipse.org_
 
<mailto:frederic.g...@eclipse.org><_mailto:frederic.gurr@eclipse.org_

   <mailto:frederic.g...@eclipse.org>>> wrote:

 Thanks Jeff,

 I ran a SimRel aggregation build. The only change I
can
   see in the list
 of "Non Unique Versions used in repository" is that a
   different version
 of org.apache.httpcomponents.httpcore is now used.
Instead of
 4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.

 I compared
   
_http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt_



 
<http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt>



   
<_http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt_



 
<http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt>>



 and
   
_https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt_



 
<https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt>



   
<_https://hudson.eclipse.org/sim

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Frederic Gurr]

>>>>>   already successful.
>>>>>
>>>>>   -- Jeff J.
>>>>>
>>>>>   On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston
>>>>> <jjohn...@redhat.com
>>>>>       <mailto:jjohn...@redhat.com>> wrote:
>>>>>
>>>>>   Marcel,
>>>>>
>>>>>   Since the respin didn't fix the problem, we will try
>>>>> reverting
>>>>>   the docker-client dependency and keeping as much of the
>>>>> added
>>>>>   Neon.3 functionality as possible
>>>>>   in place and cutting another point release.  I will let the
>>>>> list
>>>>>   know when I have something in place.
>>>>>
>>>>>   -- Jeff J.
>>>>>
>>>>>   On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
>>>>>   <daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.com>>
>>>>> wrote:
>>>>>
>>>>>   Adding eclipse.org-planning-coun...@eclipse.org
>>>>>   <mailto:eclipse.org-planning-coun...@eclipse.org> to
>>>>> this
>>>>>   thread.
>>>>>
>>>>>   Dani
>>>>>
>>>>>
>>>>>
>>>>>   From:"Dr. Marcel Bruch"
>>>>> <marcel.br...@codetrails.com
>>>>>   <mailto:marcel.br...@codetrails.com>>
>>>>>   To:Cross project issues
>>>>>   <cross-project-issues-dev@eclipse.org
>>>>>   <mailto:cross-project-issues-dev@eclipse.org>>
>>>>>   Date:21.04.2017 10:17
>>>>>   Subject:Re: [cross-project-issues-dev] Neon.3
>>>>> Update
>>>>>   Problems: To Fix andHow to Fix?
>>>>>   Sent by:
>>>>> cross-project-issues-dev-boun...@eclipse.org
>>>>>   <mailto:cross-project-issues-dev-boun...@eclipse.org>
>>>>> 
>>>>> 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   Hi,
>>>>>
>>>>>   I’ll briefly summarize the discussion we had at the AC
>>>>>   yesterday:
>>>>>
>>>>>   Given that we don’t know how the OSGI resolver will
>>>>> behave
>>>>>   (even after Tom back-ported a fix to Neon) it would be
>>>>>   preferred to just have the Apache HTTP*** versions in
>>>>> Neon.3
>>>>>   that were already in Neon.2. This would to some extend
>>>>>   “ensure" that we are "at least as as stable as Neon.2”.
>>>>> This
>>>>>   would require us to rollback the changes that introduced
>>>>> the
>>>>>   latest version of HTTPClient. As far as I know this
>>>>> would
>>>>>   especially affect the Docker Tooling. (maybe more
>>>>> changes
>>>>>   than that are needed)
>>>>>
>>>>>   My question to the *Docker Tooling project lead*: Is it
>>>>>   possible to rollback this last minute change and
>>>>> postpone it
>>>>>   to Oxygen for the sake of making EGit, MPC, Oomph,
>>>>> USS, and
>>>>>   Code Recommenders work reliably again - and giving us
>>>>> more
>>>>>   trust that we won’t get into trouble with Neon.3? The
>>>>>   simplest solution may be to contribute the docker
>>>>> tooling
>>>>>   from Neon.2 in Neon.3. WDYT?
>>>>>
>>>>>   Marcel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   On 20 Apr 2017, at 18:54, Frederic Gurr
>>>>>   <_frederic.gurr@eclipse.org_
>>>>>   <mailto:frederic.g...@eclipse.org>> wrote:
>>>>>
>>>>>   I can see
>&g

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Ed Merks]

Fred,

Installing the Eierlegende Wollmilchsau with this additional repository 
in the p2 task's repository list results in an installation without 
wiring problems.


The profile of the installation contains version 2.3.0.20170421191 of 
org.eclipse.linuxtools.docker.core with is indeed the version available 
in 
https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final 
so I think this is a good demonstration that installations creation from 
this repository's contents will not have the wiring problems we've been 
seeing in Neon.3.


Regards,
Ed



Ed,

The temporary update site URL is:

https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final

Regards,

Fred

On 25.04.2017 15:13, Ed Merks wrote:

Fred,

What update site URL contains these results?

Regards,
Ed


On 25.04.2017 14:28, Frederic Gurr wrote:

Thanks Jeff,

This is the comparison of the non-unique versions list:

neon3_respin aggregation build 20.04.
(https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):


org.apache.httpcomponents.httpclient
 4.3.6.v201411290715
 4.5.2.v20161115-1643
 4.3.6.v201511171540
 4.2.6.v201311072007
org.apache.httpcomponents.httpcore
 4.3.3.v201411290715
 4.4.6.v20170210-0925
 4.2.5.v201311072007
 
neon3_respin aggregation build 25.04.

(https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):


org.apache.httpcomponents.httpclient
 4.3.6.v201411290715
 4.3.6.v201511171540
 4.2.6.v201311072007
org.apache.httpcomponents.httpcore
 4.3.3.v201411290715
 4.2.5.v201311072007


So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6 are
not in the repo any more.

@All: Can someone confirm that this fixes the update problem (earlier
version to Neon.3)?

If it is confirmed to work, we have a fix for users that have not
upgraded to Neon.3 yet. Users that already upgraded are unaffected by
this. They still need to wait for a "wiring issue" fix.

Regards,

Fred


On 21.04.2017 23:00, Jeff Johnston wrote:

Just to confirm that the change has been merged to the Neon.3_respin
branch.

-- Jeff J.

On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com
<mailto:jjohn...@redhat.com>> wrote:

  I have done another respin.  In this case, I rebuilt the Linux
Tools
  plug-ins to use the older version
  of docker-client and its dependencies which were used in Neon.2.  I
  have back-versioned the
  Docker tooling plug-ins to 2.3.0 with the current date.

  I have just pushed to gerrit for Neon.3_respin branch.

  https://git.eclipse.org/r/#/c/95501/
  <https://git.eclipse.org/r/#/c/95501/>

  If no-one objects, I will merge into the branch.  Verification is
  already successful.

  -- Jeff J.

  On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston
<jjohn...@redhat.com
  <mailto:jjohn...@redhat.com>> wrote:

  Marcel,

  Since the respin didn't fix the problem, we will try reverting
  the docker-client dependency and keeping as much of the added
  Neon.3 functionality as possible
  in place and cutting another point release.  I will let the
list
  know when I have something in place.

  -- Jeff J.

  On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
  <daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.com>>
wrote:

  Adding eclipse.org-planning-coun...@eclipse.org
  <mailto:eclipse.org-planning-coun...@eclipse.org> to this
  thread.

  Dani



  From:"Dr. Marcel Bruch"
<marcel.br...@codetrails.com
  <mailto:marcel.br...@codetrails.com>>
  To:Cross project issues
  <cross-project-issues-dev@eclipse.org
  <mailto:cross-project-issues-dev@eclipse.org>>
          Date:    21.04.2017 10:17
      Subject:        Re: [cross-project-issues-dev] Neon.3
Update
  Problems: To Fix andHow to Fix?
  Sent by:
cross-project-issues-dev-boun...@eclipse.org
  <mailto:cross-project-issues-dev-boun...@eclipse.org>
 





  Hi,

  I’ll briefly summarize the discussion we had at the AC
  yesterday:

  Given that we don’t know how the OSGI resolver will behave
  (even after Tom back-ported a fix to Neon) it would be
  preferred to just have the Apache HTTP*** versions in
Neon.3
  that were alre

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Frederic Gurr]

Ed,

The temporary update site URL is:

https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final

Regards,

Fred

On 25.04.2017 15:13, Ed Merks wrote:
> Fred,
> 
> What update site URL contains these results?
> 
> Regards,
> Ed
> 
> 
> On 25.04.2017 14:28, Frederic Gurr wrote:
>> Thanks Jeff,
>>
>> This is the comparison of the non-unique versions list:
>>
>> neon3_respin aggregation build 20.04.
>> (https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):
>>
>>
>> org.apache.httpcomponents.httpclient
>> 4.3.6.v201411290715
>> 4.5.2.v20161115-1643
>> 4.3.6.v201511171540
>> 4.2.6.v201311072007
>> org.apache.httpcomponents.httpcore
>> 4.3.3.v201411290715
>> 4.4.6.v20170210-0925
>> 4.2.5.v201311072007
>> 
>> neon3_respin aggregation build 25.04.
>> (https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):
>>
>>
>> org.apache.httpcomponents.httpclient
>> 4.3.6.v201411290715
>> 4.3.6.v201511171540
>> 4.2.6.v201311072007
>> org.apache.httpcomponents.httpcore
>> 4.3.3.v201411290715
>> 4.2.5.v201311072007
>>
>>
>> So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6 are
>> not in the repo any more.
>>
>> @All: Can someone confirm that this fixes the update problem (earlier
>> version to Neon.3)?
>>
>> If it is confirmed to work, we have a fix for users that have not
>> upgraded to Neon.3 yet. Users that already upgraded are unaffected by
>> this. They still need to wait for a "wiring issue" fix.
>>
>> Regards,
>>
>> Fred
>>
>>
>> On 21.04.2017 23:00, Jeff Johnston wrote:
>>> Just to confirm that the change has been merged to the Neon.3_respin
>>> branch.
>>>
>>> -- Jeff J.
>>>
>>> On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com
>>> <mailto:jjohn...@redhat.com>> wrote:
>>>
>>>  I have done another respin.  In this case, I rebuilt the Linux
>>> Tools
>>>  plug-ins to use the older version
>>>  of docker-client and its dependencies which were used in Neon.2.  I
>>>  have back-versioned the
>>>  Docker tooling plug-ins to 2.3.0 with the current date.
>>>
>>>  I have just pushed to gerrit for Neon.3_respin branch.
>>>
>>>  https://git.eclipse.org/r/#/c/95501/
>>>  <https://git.eclipse.org/r/#/c/95501/>
>>>
>>>  If no-one objects, I will merge into the branch.  Verification is
>>>  already successful.
>>>
>>>  -- Jeff J.
>>>
>>>  On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston
>>> <jjohn...@redhat.com
>>>  <mailto:jjohn...@redhat.com>> wrote:
>>>
>>>  Marcel,
>>>
>>>  Since the respin didn't fix the problem, we will try reverting
>>>  the docker-client dependency and keeping as much of the added
>>>  Neon.3 functionality as possible
>>>  in place and cutting another point release.  I will let the
>>> list
>>>  know when I have something in place.
>>>
>>>  -- Jeff J.
>>>
>>>  On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
>>>  <daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.com>>
>>> wrote:
>>>
>>>  Adding eclipse.org-planning-coun...@eclipse.org
>>>  <mailto:eclipse.org-planning-coun...@eclipse.org> to this
>>>  thread.
>>>
>>>  Dani
>>>
>>>
>>>
>>>  From:"Dr. Marcel Bruch"
>>> <marcel.br...@codetrails.com
>>>  <mailto:marcel.br...@codetrails.com>>
>>>  To:Cross project issues
>>>  <cross-project-issues-dev@eclipse.org
>>>  <mailto:cross-project-issues-dev@eclipse.org>>
>>>  Date:21.04.2017 10:17
>>>  Subject:Re: [cross-project-issues-dev] Neon.3
>>> Update
>>>  Problems: To Fix andHow to Fix?
>>>   

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Ed Merks]

Fred,

What update site URL contains these results?

Regards,
Ed


On 25.04.2017 14:28, Frederic Gurr wrote:

Thanks Jeff,

This is the comparison of the non-unique versions list:

neon3_respin aggregation build 20.04.
(https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):

org.apache.httpcomponents.httpclient
4.3.6.v201411290715
4.5.2.v20161115-1643
4.3.6.v201511171540
4.2.6.v201311072007
org.apache.httpcomponents.httpcore
4.3.3.v201411290715
4.4.6.v20170210-0925
4.2.5.v201311072007

neon3_respin aggregation build 25.04.
(https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):

org.apache.httpcomponents.httpclient
4.3.6.v201411290715
4.3.6.v201511171540
4.2.6.v201311072007
org.apache.httpcomponents.httpcore
4.3.3.v201411290715
4.2.5.v201311072007


So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6 are
not in the repo any more.

@All: Can someone confirm that this fixes the update problem (earlier
version to Neon.3)?

If it is confirmed to work, we have a fix for users that have not
upgraded to Neon.3 yet. Users that already upgraded are unaffected by
this. They still need to wait for a "wiring issue" fix.

Regards,

Fred


On 21.04.2017 23:00, Jeff Johnston wrote:

Just to confirm that the change has been merged to the Neon.3_respin branch.

-- Jeff J.

On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com
<mailto:jjohn...@redhat.com>> wrote:

 I have done another respin.  In this case, I rebuilt the Linux Tools
 plug-ins to use the older version
 of docker-client and its dependencies which were used in Neon.2.  I
 have back-versioned the
 Docker tooling plug-ins to 2.3.0 with the current date.

 I have just pushed to gerrit for Neon.3_respin branch.

 https://git.eclipse.org/r/#/c/95501/
 <https://git.eclipse.org/r/#/c/95501/>

 If no-one objects, I will merge into the branch.  Verification is
 already successful.

 -- Jeff J.

 On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston <jjohn...@redhat.com
 <mailto:jjohn...@redhat.com>> wrote:

 Marcel,

 Since the respin didn't fix the problem, we will try reverting
 the docker-client dependency and keeping as much of the added
 Neon.3 functionality as possible
 in place and cutting another point release.  I will let the list
 know when I have something in place.

 -- Jeff J.

 On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
 <daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.com>> wrote:

 Adding eclipse.org-planning-coun...@eclipse.org
 <mailto:eclipse.org-planning-coun...@eclipse.org> to this
 thread.

 Dani



 From:"Dr. Marcel Bruch" <marcel.br...@codetrails.com
 <mailto:marcel.br...@codetrails.com>>
 To:Cross project issues
 <cross-project-issues-dev@eclipse.org
 <mailto:cross-project-issues-dev@eclipse.org>>
         Date:    21.04.2017 10:17
         Subject:        Re: [cross-project-issues-dev] Neon.3 Update
 Problems: To Fix andHow to Fix?
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 <mailto:cross-project-issues-dev-boun...@eclipse.org>
 




 Hi,

 I’ll briefly summarize the discussion we had at the AC
 yesterday:

 Given that we don’t know how the OSGI resolver will behave
 (even after Tom back-ported a fix to Neon) it would be
 preferred to just have the Apache HTTP*** versions in Neon.3
 that were already in Neon.2. This would to some extend
 “ensure" that we are "at least as as stable as Neon.2”. This
 would require us to rollback the changes that introduced the
 latest version of HTTPClient. As far as I know this would
 especially affect the Docker Tooling. (maybe more changes
 than that are needed)

 My question to the *Docker Tooling project lead*: Is it
 possible to rollback this last minute change and postpone it
 to Oxygen for the sake of making EGit, MPC, Oomph, USS, and
 Code Recommenders work reliably again - and giving us more
 trust that we won’t get into trouble with Neon.3? The
 simplest solution may be to contribute the docker tooling
   

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Daniel Megert]

> Users that already upgraded are unaffected by this. They still need to 
wait for a "wiring issue" fix.

Why is that? If they upgrade from Neon.3 to Neon.3a I would expect it 
disables the broken bundles and things work. Like I can also update from 
Neon.0 to Neon.3a.

Dani



From:   Frederic Gurr <frederic.g...@eclipse.org>
To: cross-project-issues-dev@eclipse.org
Date:   25.04.2017 14:28
Subject:    Re: [cross-project-issues-dev] Neon.3 Update Problems: To 
Fix and How to Fix?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Thanks Jeff,

This is the comparison of the non-unique versions list:

neon3_respin aggregation build 20.04.
(
https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt
):

org.apache.httpcomponents.httpclient
 4.3.6.v201411290715
 4.5.2.v20161115-1643
 4.3.6.v201511171540
 4.2.6.v201311072007
org.apache.httpcomponents.httpcore
 4.3.3.v201411290715
 4.4.6.v20170210-0925
 4.2.5.v201311072007
 
neon3_respin aggregation build 25.04.
(
https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt
):

org.apache.httpcomponents.httpclient
 4.3.6.v201411290715
 4.3.6.v201511171540
 4.2.6.v201311072007
org.apache.httpcomponents.httpcore
 4.3.3.v201411290715
 4.2.5.v201311072007


So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6 are
not in the repo any more.

@All: Can someone confirm that this fixes the update problem (earlier
version to Neon.3)?

If it is confirmed to work, we have a fix for users that have not
upgraded to Neon.3 yet. Users that already upgraded are unaffected by
this. They still need to wait for a "wiring issue" fix.

Regards,

Fred


On 21.04.2017 23:00, Jeff Johnston wrote:
> Just to confirm that the change has been merged to the Neon.3_respin 
branch.
> 
> -- Jeff J.
> 
> On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com
> <mailto:jjohn...@redhat.com>> wrote:
> 
> I have done another respin.  In this case, I rebuilt the Linux Tools
> plug-ins to use the older version
> of docker-client and its dependencies which were used in Neon.2.  I
> have back-versioned the
> Docker tooling plug-ins to 2.3.0 with the current date.
> 
> I have just pushed to gerrit for Neon.3_respin branch.
> 
> https://git.eclipse.org/r/#/c/95501/
> <https://git.eclipse.org/r/#/c/95501/>
> 
> If no-one objects, I will merge into the branch.  Verification is
> already successful.
> 
> -- Jeff J.
> 
> On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston <jjohn...@redhat.com
> <mailto:jjohn...@redhat.com>> wrote:
> 
> Marcel,
> 
> Since the respin didn't fix the problem, we will try reverting
> the docker-client dependency and keeping as much of the added
> Neon.3 functionality as possible
> in place and cutting another point release.  I will let the list
> know when I have something in place.
> 
> -- Jeff J.
> 
> On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
> <daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.com>> 
wrote:
> 
> Adding eclipse.org-planning-coun...@eclipse.org
> <mailto:eclipse.org-planning-coun...@eclipse.org> to this
> thread.
> 
> Dani
> 
> 
> 
> From:"Dr. Marcel Bruch" <marcel.br...@codetrails.com
> <mailto:marcel.br...@codetrails.com>>
>         To:        Cross project issues
>     <cross-project-issues-dev@eclipse.org
> <mailto:cross-project-issues-dev@eclipse.org>>
> Date:21.04.2017 10:17
> Subject:Re: [cross-project-issues-dev] Neon.3 Update
> Problems: To Fix andHow to Fix?
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> <mailto:cross-project-issues-dev-boun...@eclipse.org>
> 
> 
> 
> 
> Hi,
> 
> I?ll briefly summarize the discussion we had at the AC
> yesterday:
> 
> Given that we don?t know how the OSGI resolver will behave
> (even after Tom back-ported a fix to Neon) it would be
> preferred to just have the Apache HTTP*** versions i

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Frederic Gurr]

Thanks Jeff,

This is the comparison of the non-unique versions list:

neon3_respin aggregation build 20.04.
(https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):

org.apache.httpcomponents.httpclient
4.3.6.v201411290715
4.5.2.v20161115-1643
4.3.6.v201511171540
4.2.6.v201311072007
org.apache.httpcomponents.httpcore
4.3.3.v201411290715
4.4.6.v20170210-0925
4.2.5.v201311072007

neon3_respin aggregation build 25.04.
(https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):

org.apache.httpcomponents.httpclient
4.3.6.v201411290715
4.3.6.v201511171540
4.2.6.v201311072007
org.apache.httpcomponents.httpcore
4.3.3.v201411290715
4.2.5.v201311072007


So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6 are
not in the repo any more.

@All: Can someone confirm that this fixes the update problem (earlier
version to Neon.3)?

If it is confirmed to work, we have a fix for users that have not
upgraded to Neon.3 yet. Users that already upgraded are unaffected by
this. They still need to wait for a "wiring issue" fix.

Regards,

Fred


On 21.04.2017 23:00, Jeff Johnston wrote:
> Just to confirm that the change has been merged to the Neon.3_respin branch.
> 
> -- Jeff J.
> 
> On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com
> <mailto:jjohn...@redhat.com>> wrote:
> 
> I have done another respin.  In this case, I rebuilt the Linux Tools
> plug-ins to use the older version
> of docker-client and its dependencies which were used in Neon.2.  I
> have back-versioned the
> Docker tooling plug-ins to 2.3.0 with the current date.
> 
> I have just pushed to gerrit for Neon.3_respin branch.
> 
> https://git.eclipse.org/r/#/c/95501/
> <https://git.eclipse.org/r/#/c/95501/>
> 
> If no-one objects, I will merge into the branch.  Verification is
> already successful.
> 
> -- Jeff J.
> 
> On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston <jjohn...@redhat.com
> <mailto:jjohn...@redhat.com>> wrote:
> 
> Marcel,
> 
> Since the respin didn't fix the problem, we will try reverting
> the docker-client dependency and keeping as much of the added
> Neon.3 functionality as possible
> in place and cutting another point release.  I will let the list
> know when I have something in place.
> 
> -- Jeff J.
> 
> On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
> <daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.com>> wrote:
> 
> Adding eclipse.org-planning-coun...@eclipse.org
> <mailto:eclipse.org-planning-coun...@eclipse.org> to this
> thread.
> 
> Dani
> 
> 
> 
> From:"Dr. Marcel Bruch" <marcel.br...@codetrails.com
> <mailto:marcel.br...@codetrails.com>>
>         To:    Cross project issues
> <cross-project-issues-dev@eclipse.org
> <mailto:cross-project-issues-dev@eclipse.org>>
> Date:21.04.2017 10:17
> Subject:Re: [cross-project-issues-dev] Neon.3 Update
> Problems: To Fix andHow to Fix?
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> <mailto:cross-project-issues-dev-boun...@eclipse.org>
> 
> 
> 
> 
> 
> Hi,
> 
> I’ll briefly summarize the discussion we had at the AC
> yesterday:
> 
> Given that we don’t know how the OSGI resolver will behave
> (even after Tom back-ported a fix to Neon) it would be
> preferred to just have the Apache HTTP*** versions in Neon.3
> that were already in Neon.2. This would to some extend
> “ensure" that we are "at least as as stable as Neon.2”. This
> would require us to rollback the changes that introduced the
> latest version of HTTPClient. As far as I know this would
> especially affect the Docker Tooling. (maybe more changes
> than that are needed)
> 
> My question to the *Docker Tooling project lead*: Is it
> possible to rollback this last minute change and postpone it
> to Oxygen for the sake of making EGit, MPC, Oomph, U

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Scott Lewis]

I am not on planning council, and so have not been able to follow all 
the discussion, but just to be clear ECF has this open bug for Oxygen M7:


https://bugs.eclipse.org/bugs/show_bug.cgi?id=513888

To meet this we have modified our own build to include these versions 
from Orbit:


org.apache.httpcomponents.httpcore_4.4.6.v20170210-0925.jar
org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925.jar

It's our intention to contribute to platform an ECF build including 
these bundles during the week of May 1.


If any of this should change because of issues from this thread, please 
let use know via bug 513888 and/or other bugs.


Scott


On 4/21/2017 2:00 PM, Jeff Johnston wrote:
Just to confirm that the change has been merged to the Neon.3_respin 
branch.


-- Jeff J.

On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com 
<mailto:jjohn...@redhat.com>> wrote:


I have done another respin.  In this case, I rebuilt the Linux
Tools plug-ins to use the older version
of docker-client and its dependencies which were used in Neon.2. 
I have back-versioned the

Docker tooling plug-ins to 2.3.0 with the current date.

I have just pushed to gerrit for Neon.3_respin branch.

https://git.eclipse.org/r/#/c/95501/
<https://git.eclipse.org/r/#/c/95501/>

If no-one objects, I will merge into the branch. Verification is
already successful.

-- Jeff J.

On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston
<jjohn...@redhat.com <mailto:jjohn...@redhat.com>> wrote:

Marcel,

Since the respin didn't fix the problem, we will try reverting
the docker-client dependency and keeping as much of the added
Neon.3 functionality as possible
in place and cutting another point release.  I will let the
list know when I have something in place.

-- Jeff J.

On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
<daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.com>>
wrote:

Adding eclipse.org-planning-coun...@eclipse.org
<mailto:eclipse.org-planning-coun...@eclipse.org> to this
thread.

Dani



From: "Dr. Marcel Bruch" <marcel.br...@codetrails.com
<mailto:marcel.br...@codetrails.com>>
To: Cross project issues
<cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>>
        Date: 21.04.2017 10:17
    Subject: Re: [cross-project-issues-dev] Neon.3 Update
Problems: To Fix andHow to Fix?
Sent by: cross-project-issues-dev-boun...@eclipse.org
<mailto:cross-project-issues-dev-boun...@eclipse.org>





Hi,

I’ll briefly summarize the discussion we had at the AC
yesterday:

Given that we don’t know how the OSGI resolver will behave
(even after Tom back-ported a fix to Neon) it would be
preferred to just have the Apache HTTP*** versions in
Neon.3 that were already in Neon.2. This would to some
extend “ensure" that we are "at least as as stable as
Neon.2”. This would require us to rollback the changes
that introduced the latest version of HTTPClient. As far
as I know this would especially affect the Docker Tooling.
(maybe more changes than that are needed)

My question to the *Docker Tooling project lead*: Is it
possible to rollback this last minute change and postpone
it to Oxygen for the sake of making EGit, MPC, Oomph, USS,
and Code Recommenders work reliably again - and giving us
more trust that we won’t get into trouble with Neon.3? The
simplest solution may be to contribute the docker tooling
from Neon.2 in Neon.3. WDYT?

Marcel




On 20 Apr 2017, at 18:54, Frederic Gurr
<_frederic.gurr@eclipse.org_
<mailto:frederic.g...@eclipse.org>> wrote:

I can see
org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in

/home/data/httpd/_download.eclipse.org/linuxtools/update-docker-2.3.1/plugins_

<http://download.eclipse.org/linuxtools/update-docker-2.3.1/plugins>,
but it's definitely not in the aggregated repo.


On 20.04.2017 18:31, Jeff Johnston wrote:
Fred,

The version of httpclient also changed in our
update-docker-2.3.1 repo from:

org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643

to:

org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925

Not sure why this cha

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Jeff Johnston]

Just to confirm that the change has been merged to the Neon.3_respin branch.

-- Jeff J.

On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com> wrote:

> I have done another respin.  In this case, I rebuilt the Linux Tools
> plug-ins to use the older version
> of docker-client and its dependencies which were used in Neon.2.  I have
> back-versioned the
> Docker tooling plug-ins to 2.3.0 with the current date.
>
> I have just pushed to gerrit for Neon.3_respin branch.
>
> https://git.eclipse.org/r/#/c/95501/
>
> If no-one objects, I will merge into the branch.  Verification is already
> successful.
>
> -- Jeff J.
>
> On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston <jjohn...@redhat.com>
> wrote:
>
>> Marcel,
>>
>> Since the respin didn't fix the problem, we will try reverting the
>> docker-client dependency and keeping as much of the added Neon.3
>> functionality as possible
>> in place and cutting another point release.  I will let the list know
>> when I have something in place.
>>
>> -- Jeff J.
>>
>> On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert <daniel_meg...@ch.ibm.com>
>> wrote:
>>
>>> Adding eclipse.org-planning-coun...@eclipse.org to this thread.
>>>
>>> Dani
>>>
>>>
>>>
>>> From:    "Dr. Marcel Bruch" <marcel.br...@codetrails.com>
>>> To:Cross project issues <cross-project-issues-dev@eclipse.org>
>>> Date:21.04.2017 10:17
>>> Subject:Re: [cross-project-issues-dev] Neon.3 Update Problems:
>>> To Fix andHow to Fix?
>>> Sent by:cross-project-issues-dev-boun...@eclipse.org
>>> --
>>>
>>>
>>>
>>> Hi,
>>>
>>> I’ll briefly summarize the discussion we had at the AC yesterday:
>>>
>>> Given that we don’t know how the OSGI resolver will behave (even after
>>> Tom back-ported a fix to Neon) it would be preferred to just have the
>>> Apache HTTP*** versions in Neon.3 that were already in Neon.2. This would
>>> to some extend “ensure" that we are "at least as as stable as Neon.2”. This
>>> would require us to rollback the changes that introduced the latest version
>>> of HTTPClient. As far as I know this would especially affect the Docker
>>> Tooling. (maybe more changes than that are needed)
>>>
>>> My question to the *Docker Tooling project lead*: Is it possible to
>>> rollback this last minute change and postpone it to Oxygen for the sake of
>>> making EGit, MPC, Oomph, USS, and Code Recommenders work reliably again -
>>> and giving us more trust that we won’t get into trouble with Neon.3? The
>>> simplest solution may be to contribute the docker tooling from Neon.2 in
>>> Neon.3. WDYT?
>>>
>>> Marcel
>>>
>>>
>>>
>>>
>>> On 20 Apr 2017, at 18:54, Frederic Gurr <*frederic.g...@eclipse.org*
>>> <frederic.g...@eclipse.org>> wrote:
>>>
>>> I can see org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in
>>> /home/data/httpd/
>>> *download.eclipse.org/linuxtools/update-docker-2.3.1/plugins*
>>> <http://download.eclipse.org/linuxtools/update-docker-2.3.1/plugins>,
>>> but it's definitely not in the aggregated repo.
>>>
>>>
>>> On 20.04.2017 18:31, Jeff Johnston wrote:
>>> Fred,
>>>
>>> The version of httpclient also changed in our update-docker-2.3.1 repo
>>> from:
>>>
>>> org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643
>>>
>>> to:
>>>
>>> org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925
>>>
>>> Not sure why this change isn't being seen as well.
>>>
>>> -- Jeff J.
>>>
>>>
>>>
>>> On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr
>>> <*frederic.g...@eclipse.org* <frederic.g...@eclipse.org><
>>> *mailto:frederic.g...@eclipse.org* <frederic.g...@eclipse.org>>> wrote:
>>>
>>>   Thanks Jeff,
>>>
>>>   I ran a SimRel aggregation build. The only change I can see in the list
>>>   of "Non Unique Versions used in repository" is that a different version
>>>   of org.apache.httpcomponents.httpcore is now used. Instead of
>>>   4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.
>>>
>>>   I compared
>>>
>>> *http://download.eclipse.org/releases/neon/201703

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Jeff Johnston]

I have done another respin.  In this case, I rebuilt the Linux Tools
plug-ins to use the older version
of docker-client and its dependencies which were used in Neon.2.  I have
back-versioned the
Docker tooling plug-ins to 2.3.0 with the current date.

I have just pushed to gerrit for Neon.3_respin branch.

https://git.eclipse.org/r/#/c/95501/

If no-one objects, I will merge into the branch.  Verification is already
successful.

-- Jeff J.

On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston <jjohn...@redhat.com> wrote:

> Marcel,
>
> Since the respin didn't fix the problem, we will try reverting the
> docker-client dependency and keeping as much of the added Neon.3
> functionality as possible
> in place and cutting another point release.  I will let the list know when
> I have something in place.
>
> -- Jeff J.
>
> On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert <daniel_meg...@ch.ibm.com>
> wrote:
>
>> Adding eclipse.org-planning-coun...@eclipse.org to this thread.
>>
>> Dani
>>
>>
>>
>> From:"Dr. Marcel Bruch" <marcel.br...@codetrails.com>
>> To:    Cross project issues <cross-project-issues-dev@eclipse.org>
>> Date:21.04.2017 10:17
>> Subject:Re: [cross-project-issues-dev] Neon.3 Update Problems:
>> To Fix andHow to Fix?
>> Sent by:cross-project-issues-dev-boun...@eclipse.org
>> --
>>
>>
>>
>> Hi,
>>
>> I’ll briefly summarize the discussion we had at the AC yesterday:
>>
>> Given that we don’t know how the OSGI resolver will behave (even after
>> Tom back-ported a fix to Neon) it would be preferred to just have the
>> Apache HTTP*** versions in Neon.3 that were already in Neon.2. This would
>> to some extend “ensure" that we are "at least as as stable as Neon.2”. This
>> would require us to rollback the changes that introduced the latest version
>> of HTTPClient. As far as I know this would especially affect the Docker
>> Tooling. (maybe more changes than that are needed)
>>
>> My question to the *Docker Tooling project lead*: Is it possible to
>> rollback this last minute change and postpone it to Oxygen for the sake of
>> making EGit, MPC, Oomph, USS, and Code Recommenders work reliably again -
>> and giving us more trust that we won’t get into trouble with Neon.3? The
>> simplest solution may be to contribute the docker tooling from Neon.2 in
>> Neon.3. WDYT?
>>
>> Marcel
>>
>>
>>
>>
>> On 20 Apr 2017, at 18:54, Frederic Gurr <*frederic.g...@eclipse.org*
>> <frederic.g...@eclipse.org>> wrote:
>>
>> I can see org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in
>> /home/data/httpd/
>> *download.eclipse.org/linuxtools/update-docker-2.3.1/plugins*
>> <http://download.eclipse.org/linuxtools/update-docker-2.3.1/plugins>,
>> but it's definitely not in the aggregated repo.
>>
>>
>> On 20.04.2017 18:31, Jeff Johnston wrote:
>> Fred,
>>
>> The version of httpclient also changed in our update-docker-2.3.1 repo
>> from:
>>
>> org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643
>>
>> to:
>>
>> org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925
>>
>> Not sure why this change isn't being seen as well.
>>
>> -- Jeff J.
>>
>>
>>
>> On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr
>> <*frederic.g...@eclipse.org* <frederic.g...@eclipse.org><
>> *mailto:frederic.g...@eclipse.org* <frederic.g...@eclipse.org>>> wrote:
>>
>>   Thanks Jeff,
>>
>>   I ran a SimRel aggregation build. The only change I can see in the list
>>   of "Non Unique Versions used in repository" is that a different version
>>   of org.apache.httpcomponents.httpcore is now used. Instead of
>>   4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.
>>
>>   I compared
>>
>> *http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt*
>> <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt>
>>   <
>> *http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt*
>> <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt>
>> >
>>   and
>>
>> *https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersio

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Jeff Johnston]

Marcel,

Since the respin didn't fix the problem, we will try reverting the
docker-client dependency and keeping as much of the added Neon.3
functionality as possible
in place and cutting another point release.  I will let the list know when
I have something in place.

-- Jeff J.

On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert <daniel_meg...@ch.ibm.com>
wrote:

> Adding eclipse.org-planning-coun...@eclipse.org to this thread.
>
> Dani
>
>
>
> From:"Dr. Marcel Bruch" <marcel.br...@codetrails.com>
> To:Cross project issues <cross-project-issues-dev@eclipse.org>
> Date:    21.04.2017 10:17
> Subject:    Re: [cross-project-issues-dev] Neon.3 Update Problems: To
> Fix andHow to Fix?
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> --
>
>
>
> Hi,
>
> I’ll briefly summarize the discussion we had at the AC yesterday:
>
> Given that we don’t know how the OSGI resolver will behave (even after Tom
> back-ported a fix to Neon) it would be preferred to just have the Apache
> HTTP*** versions in Neon.3 that were already in Neon.2. This would to some
> extend “ensure" that we are "at least as as stable as Neon.2”. This would
> require us to rollback the changes that introduced the latest version of
> HTTPClient. As far as I know this would especially affect the Docker
> Tooling. (maybe more changes than that are needed)
>
> My question to the *Docker Tooling project lead*: Is it possible to
> rollback this last minute change and postpone it to Oxygen for the sake of
> making EGit, MPC, Oomph, USS, and Code Recommenders work reliably again -
> and giving us more trust that we won’t get into trouble with Neon.3? The
> simplest solution may be to contribute the docker tooling from Neon.2 in
> Neon.3. WDYT?
>
> Marcel
>
>
>
>
> On 20 Apr 2017, at 18:54, Frederic Gurr <*frederic.g...@eclipse.org*
> <frederic.g...@eclipse.org>> wrote:
>
> I can see org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in
> /home/data/httpd/
> *download.eclipse.org/linuxtools/update-docker-2.3.1/plugins*
> <http://download.eclipse.org/linuxtools/update-docker-2.3.1/plugins>,
> but it's definitely not in the aggregated repo.
>
>
> On 20.04.2017 18:31, Jeff Johnston wrote:
> Fred,
>
> The version of httpclient also changed in our update-docker-2.3.1 repo
> from:
>
> org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643
>
> to:
>
> org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925
>
> Not sure why this change isn't being seen as well.
>
> -- Jeff J.
>
>
>
> On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr
> <*frederic.g...@eclipse.org* <frederic.g...@eclipse.org><
> *mailto:frederic.g...@eclipse.org* <frederic.g...@eclipse.org>>> wrote:
>
>   Thanks Jeff,
>
>   I ran a SimRel aggregation build. The only change I can see in the list
>   of "Non Unique Versions used in repository" is that a different version
>   of org.apache.httpcomponents.httpcore is now used. Instead of
>   4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.
>
>   I compared
>
> *http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt*
> <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt>
>   <
> *http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt*
> <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt>
> >
>   and
>
> *https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt*
> <https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt>
>   <
> *https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt*
> <https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt>
> >
>
>   @All: is that the intended result?
>
>   Regards,
>
>   Fred
>
>
>   On 19.04.2017 20:21, Jeff Johnston wrote:
> Hi Fred,
>
> I have just pushed a change to gerrit:
>*https://git.eclipse.org/r/#/c/95308/*
> <https://git.eclipse.org/r/#/c/95308/>
>   <*https://git.eclipse.org/r/#/c/95308/*
> <https://git.eclipse.org/r/#/c/95308/>&

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Daniel Megert]

Adding eclipse.org-planning-coun...@eclipse.org to this thread.

Dani



From:   "Dr. Marcel Bruch" <marcel.br...@codetrails.com>
To: Cross project issues <cross-project-issues-dev@eclipse.org>
Date:   21.04.2017 10:17
Subject:    Re: [cross-project-issues-dev] Neon.3 Update Problems: To 
Fix and How to Fix?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

I?ll briefly summarize the discussion we had at the AC yesterday:

Given that we don?t know how the OSGI resolver will behave (even after Tom 
back-ported a fix to Neon) it would be preferred to just have the Apache 
HTTP*** versions in Neon.3 that were already in Neon.2. This would to some 
extend ?ensure" that we are "at least as as stable as Neon.2?. This would 
require us to rollback the changes that introduced the latest version of 
HTTPClient. As far as I know this would especially affect the Docker 
Tooling. (maybe more changes than that are needed)

My question to the Docker Tooling project lead: Is it possible to rollback 
this last minute change and postpone it to Oxygen for the sake of making 
EGit, MPC, Oomph, USS, and Code Recommenders work reliably again - and 
giving us more trust that we won?t get into trouble with Neon.3? The 
simplest solution may be to contribute the docker tooling from Neon.2 in 
Neon.3. WDYT?

Marcel




On 20 Apr 2017, at 18:54, Frederic Gurr <frederic.g...@eclipse.org> wrote:

I can see org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in
/home/data/httpd/
download.eclipse.org/linuxtools/update-docker-2.3.1/plugins,
but it's definitely not in the aggregated repo.


On 20.04.2017 18:31, Jeff Johnston wrote:
Fred,

The version of httpclient also changed in our update-docker-2.3.1 repo 
from:

org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643

to:

org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925

Not sure why this change isn't being seen as well.

-- Jeff J.



On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr
<frederic.g...@eclipse.org<mailto:frederic.g...@eclipse.org>> wrote:

   Thanks Jeff,

   I ran a SimRel aggregation build. The only change I can see in the list
   of "Non Unique Versions used in repository" is that a different version
   of org.apache.httpcomponents.httpcore is now used. Instead of
   4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.

   I compared
   
http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt

   <
http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt
>
   and
   
https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt

   <
https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt
>

   @All: is that the intended result?

   Regards,

   Fred


   On 19.04.2017 20:21, Jeff Johnston wrote:
Hi Fred,

I have just pushed a change to gerrit:
   https://git.eclipse.org/r/#/c/95308/
   <https://git.eclipse.org/r/#/c/95308/>

I only changed the docker repository and left the other Linux Tools
features alone
since they were only bumped as part of the point release to fix the
Docker Tooling plug-ins.

I assume I can merge the patch if the gerrit verification is
successful.  If this is wrong,
let me know.

-- Jeff J.

On Wed, Apr 19, 2017 at 1:08 PM, Frederic Gurr
<frederic.g...@eclipse.org<mailto:frederic.g...@eclipse.org>
   <mailto:frederic.g...@eclipse.org
   <mailto:frederic.g...@eclipse.org>>> wrote:

   Hi,

   Can you provide a patch for the SimRel build (branch
   "Neon.3_respin")
   that references the new version?

   Regards,

   Fred

   On 19.04.2017 17:27, Jeff Johnston wrote:
Hi Ed,

Linux tools spun a 5.3.1 release which now has a 2.3.1
   version of
   docker
tooling.  The Linux tools download site has
   update-docker-2.3.1 and
update-docker, both which have 2.3.1 versions of the docker.core
   plug-in
and docker feature.  Not sure why you are not seeing this.

-- Jeff J.

On Wed, Apr 19, 2017 at 11:13 AM, Ed Merks
   <ed.me...@gmail.com <mailto:ed.me...@gmail.com>
   <mailto:ed.me...@gmail.com <mailto:ed.me...@gmail.com>>
<mailto:ed.me...@gmail.com <mailto:ed.me...@gmail.com>
   <mailto:ed.me...@gmail.com <mailto:ed.me...@gmail.com>>>> wrote:

   Frederic,

   There seem to have been no notes/minutes taken during
   the meeting:


https://wiki.eclipse.org/Planning_Council/April_05_2017
   <https://wiki.eclipse.org/Planning_Council/April_05_2017>
   <https://wiki.eclipse.org/Planning_Council/April_05_2017
   <https://wiki.eclipse.org/Planning_Council/April_05_2017>>
   <https://wiki.eclipse.org/Planning_Council/April_05_2017

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Dr. Marcel Bruch]

Hi,

I’ll briefly summarize the discussion we had at the AC yesterday:

Given that we don’t know how the OSGI resolver will behave (even after Tom 
back-ported a fix to Neon) it would be preferred to just have the Apache 
HTTP*** versions in Neon.3 that were already in Neon.2. This would to some 
extend “ensure" that we are "at least as as stable as Neon.2”. This would 
require us to rollback the changes that introduced the latest version of 
HTTPClient. As far as I know this would especially affect the Docker Tooling. 
(maybe more changes than that are needed)

My question to the Docker Tooling project lead: Is it possible to rollback this 
last minute change and postpone it to Oxygen for the sake of making EGit, MPC, 
Oomph, USS, and Code Recommenders work reliably again - and giving us more 
trust that we won’t get into trouble with Neon.3? The simplest solution may be 
to contribute the docker tooling from Neon.2 in Neon.3. WDYT?

Marcel




> On 20 Apr 2017, at 18:54, Frederic Gurr  wrote:
> 
> I can see org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in
> /home/data/httpd/download.eclipse.org/linuxtools/update-docker-2.3.1/plugins 
> ,
> but it's definitely not in the aggregated repo.
> 
> 
> On 20.04.2017 18:31, Jeff Johnston wrote:
>> Fred,
>> 
>> The version of httpclient also changed in our update-docker-2.3.1 repo from:
>> 
>> org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643
>> 
>> to:
>> 
>> org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925
>> 
>> Not sure why this change isn't being seen as well.
>> 
>> -- Jeff J.
>> 
>> 
>> 
>> On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr
>> > > >> wrote:
>> 
>>Thanks Jeff,
>> 
>>I ran a SimRel aggregation build. The only change I can see in the list
>>of "Non Unique Versions used in repository" is that a different version
>>of org.apache.httpcomponents.httpcore is now used. Instead of
>>4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.
>> 
>>I compared
>>
>> http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt
>>  
>> 
>>
>> >  
>> >
>>and
>>
>> https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt
>>  
>> 
>>
>> >  
>> >
>> 
>>@All: is that the intended result?
>> 
>>Regards,
>> 
>>Fred
>> 
>> 
>>On 19.04.2017 20:21, Jeff Johnston wrote:
>>> Hi Fred,
>>> 
>>> I have just pushed a change to gerrit:
>>https://git.eclipse.org/r/#/c/95308/ 
>> 
>>> >
>>> 
>>> I only changed the docker repository and left the other Linux Tools
>>> features alone
>>> since they were only bumped as part of the point release to fix the
>>> Docker Tooling plug-ins.
>>> 
>>> I assume I can merge the patch if the gerrit verification is
>>> successful.  If this is wrong,
>>> let me know.
>>> 
>>> -- Jeff J.
>>> 
>>> On Wed, Apr 19, 2017 at 1:08 PM, Frederic Gurr
>>> >> >> >
>>
>>> wrote:
>>> 
>>>Hi,
>>> 
>>>Can you provide a patch for the SimRel build (branch
>>"Neon.3_respin")
>>>that references the new version?
>>> 
>>>Regards,
>>> 
>>>Fred
>>> 
>>>On 19.04.2017 17:27, Jeff Johnston wrote:
 Hi Ed,
 
 Linux tools spun a 5.3.1 release which now has a 2.3.1
>>version of
>>>docker
 tooling.  The Linux tools download site has
>>update-docker-2.3.1 and
 update-docker, both which have 2.3.1 versions of the docker.core
>>>plug-in
 and docker feature.  Not sure why 

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Frederic Gurr]

I can see org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in
/home/data/httpd/download.eclipse.org/linuxtools/update-docker-2.3.1/plugins,
but it's definitely not in the aggregated repo.


On 20.04.2017 18:31, Jeff Johnston wrote:
> Fred,
> 
> The version of httpclient also changed in our update-docker-2.3.1 repo from:
> 
> org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643
> 
> to:
> 
> org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925
> 
> Not sure why this change isn't being seen as well.
> 
> -- Jeff J.
> 
> 
> 
> On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr
> > wrote:
> 
> Thanks Jeff,
> 
> I ran a SimRel aggregation build. The only change I can see in the list
> of "Non Unique Versions used in repository" is that a different version
> of org.apache.httpcomponents.httpcore is now used. Instead of
> 4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.
> 
> I compared
> 
> http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt
> 
> 
> and
> 
> https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt
> 
> 
> 
> @All: is that the intended result?
> 
> Regards,
> 
> Fred
> 
> 
> On 19.04.2017 20:21, Jeff Johnston wrote:
> > Hi Fred,
> >
> > I have just pushed a change to gerrit:
> https://git.eclipse.org/r/#/c/95308/
> 
> >
> > I only changed the docker repository and left the other Linux Tools
> > features alone
> > since they were only bumped as part of the point release to fix the
> > Docker Tooling plug-ins.
> >
> > I assume I can merge the patch if the gerrit verification is
> > successful.  If this is wrong,
> > let me know.
> >
> > -- Jeff J.
> >
> > On Wed, Apr 19, 2017 at 1:08 PM, Frederic Gurr
> > 
>  >> wrote:
> >
> > Hi,
> >
> > Can you provide a patch for the SimRel build (branch
> "Neon.3_respin")
> > that references the new version?
> >
> > Regards,
> >
> > Fred
> >
> > On 19.04.2017 17:27, Jeff Johnston wrote:
> > > Hi Ed,
> > >
> > > Linux tools spun a 5.3.1 release which now has a 2.3.1
> version of
> > docker
> > > tooling.  The Linux tools download site has
> update-docker-2.3.1 and
> > > update-docker, both which have 2.3.1 versions of the docker.core
> > plug-in
> > > and docker feature.  Not sure why you are not seeing this.
> > >
> > > -- Jeff J.
> > >
> > > On Wed, Apr 19, 2017 at 11:13 AM, Ed Merks
> 
> > >
> > > 
>  > >
> > > Frederic,
> > >
> > > There seem to have been no notes/minutes taken during
> the meeting:
> > >
> > > 
>  https://wiki.eclipse.org/Planning_Council/April_05_2017
> 
> >  >
> > >  
> >  >>
> > >
> > > I recall agreeing to provide steps for reproducing the
> problem so
> > > that Thomas Watson could test if the wiring resolution
> fix he made
> > > for Oxygen also solves the problem for Neon.3.  The fact
> that he
> > > encountered "the mirroring problem" didn't help in that
> regard:
> > >
> > >   https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213
> 
> >  >
> > >  

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Jeff Johnston]

Fred,

The version of httpclient also changed in our update-docker-2.3.1 repo from:

org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643

to:

org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925

Not sure why this change isn't being seen as well.

-- Jeff J.



On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr 
wrote:

> Thanks Jeff,
>
> I ran a SimRel aggregation build. The only change I can see in the list
> of "Non Unique Versions used in repository" is that a different version
> of org.apache.httpcomponents.httpcore is now used. Instead of
> 4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.
>
> I compared
> http://download.eclipse.org/releases/neon/201703231000/
> buildInfo/reporeports/reports/nonUniqueVersions.txt
> and
> https://hudson.eclipse.org/simrel/job/simrel.neon.3_
> respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/
> buildInfo/reporeports/reports/nonUniqueVersions.txt
>
> @All: is that the intended result?
>
> Regards,
>
> Fred
>
>
> On 19.04.2017 20:21, Jeff Johnston wrote:
> > Hi Fred,
> >
> > I have just pushed a change to gerrit: https://git.eclipse.org/r/#/c/
> 95308/
> >
> > I only changed the docker repository and left the other Linux Tools
> > features alone
> > since they were only bumped as part of the point release to fix the
> > Docker Tooling plug-ins.
> >
> > I assume I can merge the patch if the gerrit verification is
> > successful.  If this is wrong,
> > let me know.
> >
> > -- Jeff J.
> >
> > On Wed, Apr 19, 2017 at 1:08 PM, Frederic Gurr
> > > wrote:
> >
> > Hi,
> >
> > Can you provide a patch for the SimRel build (branch "Neon.3_respin")
> > that references the new version?
> >
> > Regards,
> >
> > Fred
> >
> > On 19.04.2017 17:27, Jeff Johnston wrote:
> > > Hi Ed,
> > >
> > > Linux tools spun a 5.3.1 release which now has a 2.3.1 version of
> > docker
> > > tooling.  The Linux tools download site has update-docker-2.3.1 and
> > > update-docker, both which have 2.3.1 versions of the docker.core
> > plug-in
> > > and docker feature.  Not sure why you are not seeing this.
> > >
> > > -- Jeff J.
> > >
> > > On Wed, Apr 19, 2017 at 11:13 AM, Ed Merks  > 
> > > >> wrote:
> > >
> > > Frederic,
> > >
> > > There seem to have been no notes/minutes taken during the
> meeting:
> > >
> > >   https://wiki.eclipse.org/Planning_Council/April_05_2017
> > 
> > >  > >
> > >
> > > I recall agreeing to provide steps for reproducing the problem
> so
> > > that Thomas Watson could test if the wiring resolution fix he
> made
> > > for Oxygen also solves the problem for Neon.3.  The fact that
> he
> > > encountered "the mirroring problem" didn't help in that regard:
> > >
> > >   https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213
> > 
> > >  > >
> > >
> > > In the end, he sent me a note saying (and I quote):
> > >
> > >> I see that now there is the same number of httpcomponents
> bundles
> > >> as there was in the messed up Oxygen M6 builds.  But here my
> back
> > >> port of the resolver fix does not seem to have fixed the
> issue.
> > >> I'm unsure if that is because it gave up with the sheer
> number of
> > >> bundles or if something else is going wrong.  But at this
> point
> > >> the backport of the resolver fix does not seem to be the
> solution
> > >> to the problem.
> > >
> > > I assumed (wrongly I guess) that Thomas would investigate a
> more
> > > general fix to address the wiring problem.
> > >
> > > In the end, I also wasn't sure which version of the docker
> > tools is
> > > proposed for contribution to Neon.3a.  I tried to search for
> > update
> > > sites containing it like this:
> > >
> > > Nothing looks like a new version of 2.3.  Goodness knows where
> one
> > > should find what's being proposed for contribution...
> > >
> > > In any case, the proposed "solution" (A) really just changes
> the
> > > version of httpclient to be one that's not broken (missing
> > > packages), but it doesn't change the wiring problem in any
> > > fundamental way.  There will still be the four versions that
> > can all
> > > be installed simultaneously, so we really should 

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Frederic Gurr]

Thanks Jeff,

I ran a SimRel aggregation build. The only change I can see in the list
of "Non Unique Versions used in repository" is that a different version
of org.apache.httpcomponents.httpcore is now used. Instead of
4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.

I compared
http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt
and
https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt

@All: is that the intended result?

Regards,

Fred


On 19.04.2017 20:21, Jeff Johnston wrote:
> Hi Fred,
> 
> I have just pushed a change to gerrit: https://git.eclipse.org/r/#/c/95308/
> 
> I only changed the docker repository and left the other Linux Tools
> features alone
> since they were only bumped as part of the point release to fix the
> Docker Tooling plug-ins.
> 
> I assume I can merge the patch if the gerrit verification is
> successful.  If this is wrong,
> let me know.
> 
> -- Jeff J.
> 
> On Wed, Apr 19, 2017 at 1:08 PM, Frederic Gurr
> > wrote:
> 
> Hi,
> 
> Can you provide a patch for the SimRel build (branch "Neon.3_respin")
> that references the new version?
> 
> Regards,
> 
> Fred
> 
> On 19.04.2017 17:27, Jeff Johnston wrote:
> > Hi Ed,
> >
> > Linux tools spun a 5.3.1 release which now has a 2.3.1 version of
> docker
> > tooling.  The Linux tools download site has update-docker-2.3.1 and
> > update-docker, both which have 2.3.1 versions of the docker.core
> plug-in
> > and docker feature.  Not sure why you are not seeing this.
> >
> > -- Jeff J.
> >
> > On Wed, Apr 19, 2017 at 11:13 AM, Ed Merks  
> > >> wrote:
> >
> > Frederic,
> >
> > There seem to have been no notes/minutes taken during the meeting:
> >
> >   https://wiki.eclipse.org/Planning_Council/April_05_2017
> 
> >  >
> >
> > I recall agreeing to provide steps for reproducing the problem so
> > that Thomas Watson could test if the wiring resolution fix he made
> > for Oxygen also solves the problem for Neon.3.  The fact that he
> > encountered "the mirroring problem" didn't help in that regard:
> >
> >   https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213
> 
> >  >
> >
> > In the end, he sent me a note saying (and I quote):
> >
> >> I see that now there is the same number of httpcomponents bundles
> >> as there was in the messed up Oxygen M6 builds.  But here my back
> >> port of the resolver fix does not seem to have fixed the issue.
> >> I'm unsure if that is because it gave up with the sheer number of
> >> bundles or if something else is going wrong.  But at this point
> >> the backport of the resolver fix does not seem to be the solution
> >> to the problem.
> >
> > I assumed (wrongly I guess) that Thomas would investigate a more
> > general fix to address the wiring problem.
> >
> > In the end, I also wasn't sure which version of the docker
> tools is
> > proposed for contribution to Neon.3a.  I tried to search for
> update
> > sites containing it like this:
> >
> > Nothing looks like a new version of 2.3.  Goodness knows where one
> > should find what's being proposed for contribution...
> >
> > In any case, the proposed "solution" (A) really just changes the
> > version of httpclient to be one that's not broken (missing
> > packages), but it doesn't change the wiring problem in any
> > fundamental way.  There will still be the four versions that
> can all
> > be installed simultaneously, so we really should expect the same
> > wiring problem(s).  In fact, I believe Oxygen M6 has
> effectively the
> > same four httpcomponents.httpclient bundle as does Neon.3, so
> I'm a
> > little suspicious whether the wiring problem is in fact really
> fixed
> > even for Oxygen.  We won't know until M7 and that's a month away.
> > It doesn't give me warm fuzzy feelings.
> >
> > So at this point it remains unclear the nature of the wiring
> > problem(s).  Is it a bug? Is it fixable? Does the knowledge, will,
> > and capacity to fix it 

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Dr. Marcel Bruch]

Hi Fred,

Code Recommenders also suffers from the addition of the new HTTPClient. 
Unfortunately our build master is on holidays for two weeks and I don’t know 
all details yet.

However, Bug 513809 summarizes all his findings. Maybe that bug contains 
relevant information to understand the issues Code Recommenders has and to find 
the right resolution for Neon.3a.

In a nutshell, we have a version for Oxygen M7 that should work with the latest 
HTTPClient (on the oxygen simrel update site) and the Neon version that only 
works with the old version of HTTPClient. Depending on which solution you try 
out, we may have to use different update sites.

LMK if I can be of any help here. I’m happy to test all builds to see if they 
solve all issues in Code Recommenders.

Marcel

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=513809


> On 19 Apr 2017, at 21:19, Wayne Beaton  wrote:
> 
> I've added my notes to the meeting minutes. These notes do not provide any 
> more detail than what's been discussed in this and the planning council 
> mailing lists.
> 
> My apologies for the delay.
> 
> Wayne
> 
> 
> On 19/04/17 11:13 AM, Ed Merks wrote:
>> 
>> There seem to have been no notes/minutes taken during the meeting:
>> 
>> https://wiki.eclipse.org/Planning_Council/April_05_2017
>> 
> 
> -- 
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation
> ___
> 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

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-179-131-7721
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

___
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

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Wayne Beaton]

I've added my notes to the meeting minutes. These notes do not provide 
any more detail than what's been discussed in this and the planning 
council mailing lists.


My apologies for the delay.

Wayne


On 19/04/17 11:13 AM, Ed Merks wrote:


There seem to have been no notes/minutes taken during the meeting:

https://wiki.eclipse.org/Planning_Council/April_05_2017



--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
___
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

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Carsten Reckord]

And I spoke too soon - I didn't take the bundle containments of the feature 
into account. So we now have:

> > B. Respin with the old version of httpclient: Needs a Neon.3 Orbit
> Service Release containing only the 4.3.6 version of httpclient. Needs a
> respin of Linux Tools to downgrade the version But the other depending
> projects will not be updated and so the MPC will still not work for end
> user after the update.
> 
> MPC would work fine with this, as would the Userstorage SDK. I was under
> the impression that Linux Tools couldn't do this because the security
> update they applied required the new httpclient version.

Still working fine.

> > C. Respin with the two versions of httpclient: Needs a Neon.3 Orbit
> Service Release containing the old 4.3.6 version and the fixed 4.5.2
> version of httpclient. In theory the two httpclient bundles should be able
> to work side-by-side but we've seen a lot of wiring issues in Oxygen due
> to the mix.
> 
> Judging by the issues in Oxygen, this will likely break MPC.
> [...]

Still the case.

> > D. Respin with only the new fixed version of httpclient: Needs a Neon.3
> Orbit Service Release containing only the 4.5.2 version of httpclient.
> Needs a respin of all the depending projects (Marketplace?) to update
> their ranges to the new 4.5.2 version minimum and force the update.
> 
> MPC wouldn't need a respin for this, but Userstorage will.

Actually MPC would need a respin as well to remove the 4.3.6 httpclient from 
its feature.

Also, a respin of Userstorage would require a respin of Oomph, because the 
Userstorage bundles are contained in the org.eclipse.oomph.setup.core feature.

___
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

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Carsten Reckord]

Hi,

> There seem to have been no notes/minutes taken during the meeting:
> 
>   https://wiki.eclipse.org/Planning_Council/April_05_2017
> 

Sorry, I didn't see these minutes until now, only Melanie's mail on the list. 
But there seems to be a misconception with the proposed solutions wrt MPC:

> B. Respin with the old version of httpclient: Needs a Neon.3 Orbit Service 
> Release containing only the 4.3.6 version of httpclient. Needs a respin of 
> Linux Tools to downgrade the version But the other depending projects will 
> not be updated and so the MPC will still not work for end user after the 
> update.

MPC would work fine with this, as would the Userstorage SDK. I was under the 
impression that Linux Tools couldn't do this because the security update they 
applied required the new httpclient version.

> C. Respin with the two versions of httpclient: Needs a Neon.3 Orbit Service 
> Release containing the old 4.3.6 version and the fixed 4.5.2 version of 
> httpclient. In theory the two httpclient bundles should be able to work 
> side-by-side but we've seen a lot of wiring issues in Oxygen due to the mix.

Judging by the issues in Oxygen, this will likely break MPC. 

MPC itself is fine with either version, and isn't affected by the broken 
httpclient version either (it gets all of its httpclient dependencies through 
package imports, so it won't get wired against the broken bundle).

However, MPC is exposed to httpclient directly through its own dependency and 
indirectly through Userstorage API. And since the Userstorage SDK, in an 
attempt to avoid the broken httpclient, restricts its version to [4.3,4.4) in 
Neon, we'll likely get wiring conflicts, which might or might not be solved by 
Thomas's Oxygen fix.

> D. Respin with only the new fixed version of httpclient: Needs a Neon.3 Orbit 
> Service Release containing only the 4.5.2 version of httpclient. Needs a 
> respin of all the depending projects (Marketplace?) to update their ranges to 
> the new 4.5.2 version minimum and force the update.

MPC wouldn't need a respin for this, but Userstorage will.

___
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

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Jeff Johnston]

Hi Ed,

Linux tools spun a 5.3.1 release which now has a 2.3.1 version of docker
tooling.  The Linux tools download site has update-docker-2.3.1 and
update-docker, both which have 2.3.1 versions of the docker.core plug-in
and docker feature.  Not sure why you are not seeing this.

-- Jeff J.

On Wed, Apr 19, 2017 at 11:13 AM, Ed Merks  wrote:

> Frederic,
>
> There seem to have been no notes/minutes taken during the meeting:
>
>   https://wiki.eclipse.org/Planning_Council/April_05_2017
> I recall agreeing to provide steps for reproducing the problem so that
> Thomas Watson could test if the wiring resolution fix he made for Oxygen
> also solves the problem for Neon.3.  The fact that he encountered "the
> mirroring problem" didn't help in that regard:
>
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213
>
> In the end, he sent me a note saying (and I quote):
>
> I see that now there is the same number of httpcomponents bundles as there
> was in the messed up Oxygen M6 builds.  But here my back port of the
> resolver fix does not seem to have fixed the issue.  I'm unsure if that is
> because it gave up with the sheer number of bundles or if something else is
> going wrong.  But at this point the backport of the resolver fix does not
> seem to be the solution to the problem.
>
>
> I assumed (wrongly I guess) that Thomas would investigate a more general
> fix to address the wiring problem.
>
> In the end, I also wasn't sure which version of the docker tools is
> proposed for contribution to Neon.3a.  I tried to search for update sites
> containing it like this:
>
> Nothing looks like a new version of 2.3.  Goodness knows where one should
> find what's being proposed for contribution...
>
> In any case, the proposed "solution" (A) really just changes the version
> of httpclient to be one that's not broken (missing packages), but it
> doesn't change the wiring problem in any fundamental way.  There will still
> be the four versions that can all be installed simultaneously, so we really
> should expect the same wiring problem(s).  In fact, I believe Oxygen M6 has
> effectively the same four httpcomponents.httpclient bundle as does Neon.3,
> so I'm a little suspicious whether the wiring problem is in fact really
> fixed even for Oxygen.  We won't know until M7 and that's a month away.  It
> doesn't give me warm fuzzy feelings.
>
> So at this point it remains unclear the nature of the wiring problem(s).
> Is it a bug? Is it fixable? Does the knowledge, will, and capacity to fix
> it exist?
>
> Without a fix to the wiring problem I think we can eliminate A as a
> solution, leaving B, C, and D (i.e., focus on problem avoidance
> approaches).  But I think if the wiring problem is a bug, it will come
> back, and it will raise its ugly head again when users install various
> technologies from various sources.  To my thinking, fixing the bug seems
> important.
>
> Regards,
> Ed
>
>
> On 19.04.2017 12:49, Frederic Gurr wrote:
>
> Hi Ed,
>
> In the last planning-council meeting you offered to evaluate if the
> fixed Linux Tools package works as expected and if there are still
> wiring issues.
>
> Can you give us an update on the current state?
>
> Regards,
>
> Fred
>
> On 31.03.2017 11:14, Ed Merks wrote:
>
> Hi,
>
> The original thread is fractured into many threads so its kind of
> impossible to follow each thread with a reply but I'll try at the bottom
> of this note, i.e., below the ===
>
> But before doing that, I'd like to re-focus on the most important
> questions: *We currently have a problem with Neon.3, will we fix it, and
> if so how will we fix it?*
>
> The discussion has quickly digressed (constructively) into solving the
> issue of how Orbit dependencies should be managed by projects and by the
> release train.  Unfortunately I see this as a world hunger issue; not
> one that is easily addressed and I believe not one we can wait for in
> order to solve the Neon.3 problem.  Let's face it, we've not been able
> to produce a proper Oxygen milestone in months, we still don't have one
> now, and we won't have one until next month, we hope.
>
> For Neon we've done three maintenance releases.  Neon.1 needed a respin
> and Neon.3 looks to be in need of the same thing.  Clearly something is
> seriously wrong.  But if we spend our time on solving the Orbit world
> hunger issue, will we arrive at a solution in time for Oxygen, let alone
> in time to fix Neon.3?  I am very, very doubtful.
>
> As another data point, if I install the egg-laying-wool-milk-pig for
> Neon.3.  The following happens.  I'm prompted to accept this license:
>
> Red Hat, Inc. licenses these features and plugins to you under
> certain open source licenses (or aggregations of such licenses),
> which in a particular case may include the Eclipse Public License,
> the GNU Lesser General Public License, and/or certain other open
> source licenses. For precise licensing details, consult the
> 

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Ed Merks]

Frederic,

There seem to have been no notes/minutes taken during the meeting:

  https://wiki.eclipse.org/Planning_Council/April_05_2017

I recall agreeing to provide steps for reproducing the problem so that 
Thomas Watson could test if the wiring resolution fix he made for Oxygen 
also solves the problem for Neon.3.  The fact that he encountered "the 
mirroring problem" didn't help in that regard:


  https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213

In the end, he sent me a note saying (and I quote):

I see that now there is the same number of httpcomponents bundles as 
there was in the messed up Oxygen M6 builds.  But here my back port of 
the resolver fix does not seem to have fixed the issue.  I'm unsure if 
that is because it gave up with the sheer number of bundles or if 
something else is going wrong.  But at this point the backport of the 
resolver fix does not seem to be the solution to the problem.


I assumed (wrongly I guess) that Thomas would investigate a more general 
fix to address the wiring problem.


In the end, I also wasn't sure which version of the docker tools is 
proposed for contribution to Neon.3a.  I tried to search for update 
sites containing it like this:


Nothing looks like a new version of 2.3.  Goodness knows where one 
should find what's being proposed for contribution...


In any case, the proposed "solution" (A) really just changes the version 
of httpclient to be one that's not broken (missing packages), but it 
doesn't change the wiring problem in any fundamental way.  There will 
still be the four versions that can all be installed simultaneously, so 
we really should expect the same wiring problem(s).  In fact, I believe 
Oxygen M6 has effectively the same four httpcomponents.httpclient bundle 
as does Neon.3, so I'm a little suspicious whether the wiring problem is 
in fact really fixed even for Oxygen.  We won't know until M7 and that's 
a month away.  It doesn't give me warm fuzzy feelings.


So at this point it remains unclear the nature of the wiring 
problem(s).  Is it a bug? Is it fixable? Does the knowledge, will, and 
capacity to fix it exist?


Without a fix to the wiring problem I think we can eliminate A as a 
solution, leaving B, C, and D (i.e., focus on problem avoidance 
approaches).  But I think if the wiring problem is a bug, it will come 
back, and it will raise its ugly head again when users install various 
technologies from various sources.  To my thinking, fixing the bug seems 
important.


Regards,
Ed


On 19.04.2017 12:49, Frederic Gurr wrote:

Hi Ed,

In the last planning-council meeting you offered to evaluate if the
fixed Linux Tools package works as expected and if there are still
wiring issues.

Can you give us an update on the current state?

Regards,

Fred

On 31.03.2017 11:14, Ed Merks wrote:

Hi,

The original thread is fractured into many threads so its kind of
impossible to follow each thread with a reply but I'll try at the bottom
of this note, i.e., below the ===

But before doing that, I'd like to re-focus on the most important
questions: *We currently have a problem with Neon.3, will we fix it, and
if so how will we fix it?*

The discussion has quickly digressed (constructively) into solving the
issue of how Orbit dependencies should be managed by projects and by the
release train.  Unfortunately I see this as a world hunger issue; not
one that is easily addressed and I believe not one we can wait for in
order to solve the Neon.3 problem.  Let's face it, we've not been able
to produce a proper Oxygen milestone in months, we still don't have one
now, and we won't have one until next month, we hope.

For Neon we've done three maintenance releases.  Neon.1 needed a respin
and Neon.3 looks to be in need of the same thing.  Clearly something is
seriously wrong.  But if we spend our time on solving the Orbit world
hunger issue, will we arrive at a solution in time for Oxygen, let alone
in time to fix Neon.3?  I am very, very doubtful.

As another data point, if I install the egg-laying-wool-milk-pig for
Neon.3.  The following happens.  I'm prompted to accept this license:

 Red Hat, Inc. licenses these features and plugins to you under
 certain open source licenses (or aggregations of such licenses),
 which in a particular case may include the Eclipse Public License,
 the GNU Lesser General Public License, and/or certain other open
 source licenses. For precise licensing details, consult the
 corresponding source code, or contact Red Hat, Attn: General
 Counsel, 100 East Davie St., Raleigh NC 27601 USA.

I'm not sure how this license slipped into the release train.   Aren't
there checks for this?  (Sorry to digress, but this is also unacceptable.)

Launching the final installation comes up like this:

Clearly a disgusting mess, but I've mentioned that before and the same
projects are still doing the same bad things, so we clearly all accept
this situation as normal.

The most important 

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Frederic Gurr]

Hi Ed,

In the last planning-council meeting you offered to evaluate if the
fixed Linux Tools package works as expected and if there are still
wiring issues.

Can you give us an update on the current state?

Regards,

Fred

On 31.03.2017 11:14, Ed Merks wrote:
> Hi,
> 
> The original thread is fractured into many threads so its kind of
> impossible to follow each thread with a reply but I'll try at the bottom
> of this note, i.e., below the ===
> 
> But before doing that, I'd like to re-focus on the most important
> questions: *We currently have a problem with Neon.3, will we fix it, and
> if so how will we fix it?*
> 
> The discussion has quickly digressed (constructively) into solving the
> issue of how Orbit dependencies should be managed by projects and by the
> release train.  Unfortunately I see this as a world hunger issue; not
> one that is easily addressed and I believe not one we can wait for in
> order to solve the Neon.3 problem.  Let's face it, we've not been able
> to produce a proper Oxygen milestone in months, we still don't have one
> now, and we won't have one until next month, we hope. 
> 
> For Neon we've done three maintenance releases.  Neon.1 needed a respin
> and Neon.3 looks to be in need of the same thing.  Clearly something is
> seriously wrong.  But if we spend our time on solving the Orbit world
> hunger issue, will we arrive at a solution in time for Oxygen, let alone
> in time to fix Neon.3?  I am very, very doubtful.
> 
> As another data point, if I install the egg-laying-wool-milk-pig for
> Neon.3.  The following happens.  I'm prompted to accept this license:
> 
> Red Hat, Inc. licenses these features and plugins to you under
> certain open source licenses (or aggregations of such licenses),
> which in a particular case may include the Eclipse Public License,
> the GNU Lesser General Public License, and/or certain other open
> source licenses. For precise licensing details, consult the
> corresponding source code, or contact Red Hat, Attn: General
> Counsel, 100 East Davie St., Raleigh NC 27601 USA.
> 
> I'm not sure how this license slipped into the release train.   Aren't
> there checks for this?  (Sorry to digress, but this is also unacceptable.)
> 
> Launching the final installation comes up like this:
> 
> Clearly a disgusting mess, but I've mentioned that before and the same
> projects are still doing the same bad things, so we clearly all accept
> this situation as normal.
> 
> The most important point here is the error log (first attachment) is
> full of exactly the problem indications (bundle wiring problems) we
> should have expected from the Neon.3 repository's contents, if someone
> were to install an arbitrary combination of the repository's contents. 
> It's really not so hard to test this!
> 
> If I create the same installation with my local build of the Oomph 1.8
> installer---which installs my locally built version of Oomph 1.8 so the
> Oomph setup plugins are no longer disabled because I made the
> userstorage dependency optional and eliminated the strict <=4.4 upper
> bound constraints on httpclient, which was such a bad idea I can almost
> have a canary to think this done to solve a problem with no anticipation
> of the problems it would cause---then I can visit all the preference
> pages producing the second attached much larger log.  It seems clear
> that proper testing really doesn't happen for far too many projects on
> the train.  With distributed responsibility, no one is really responsible...
> 
> ==
> 
> Orbit Issues
> 
> 1) Respinning Linux Tools against Oxygen Mx seems to miss the point that
> we should only distribute released versions of bundles,  so no Neon
> build should redistribute any unreleased version of anything.  If a new
> version of something is needed for security reasons or other reasons, it
> should be released first.  And doing that in a maintenance train without
> testing the overall impact is clearly something we should never do again
> (without waving a bunch of red flags of warning).  And as Martin
> Oberhuber asks, is nothing in place to check for this?  So suppose we do
> respin with a fixed released version, like what we have for Oxygen M6,
> then most likely we'd still have the problems we have in Oxygen M6 so
> we'd need a fix to the resolver in Neon.  Better would seem to respin
> with the old version(s) of the Orbit bundles, but somehow we can never
> delete the broken version from Neon and because it has a higher version
> number is likely to slip back in unexpected (though hopefully not, given
> that features have pinned their bundle versions).
> 
> 2) Don't include Orbit bundles in your project's features.  Sounds like
> a great idea, but begs endless questions, and while solving a problem
> might well introduce more new problems than it solves.  The first
> question (as Carsten points out) is how do these things end up in a
> repository, and if 

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Roland Grunberg]

On Fri, 2017-03-31 at 11:14 +0200, Ed Merks wrote:
> As another data point, if I install the egg-laying-wool-milk-pig for
> Neon.3.  The following happens.  I'm prompted to accept this license:
> Red Hat, Inc. licenses these features and plugins to you under
> certain open source licenses (or aggregations of such licenses),
> which in a particular case may include the Eclipse Public License,
> the GNU Lesser General Public License, and/or certain other open
> source licenses. For precise licensing details, consult the
> corresponding source code, or contact Red Hat, Attn: General Counsel,
> 100 East Davie St., Raleigh NC 27601 USA.
> I'm not sure how this license slipped into the release train.  
> Aren't there checks for this?  (Sorry to digress, but this is also
> unacceptable.)

It appears to be coming from http://git.eclipse.org/c/bpmn2-modeler/org
.eclipse.bpmn2-
modeler.git/log/features/org.eclipse.bpmn2.modeler.runtime.jboss/licens
e.html but I guess the point is if we ran even a basic install on the
content, this would have been caught much earlier.


> Orbit Issues
> 1) Respinning Linux Tools against Oxygen Mx seems to miss the point
> that we should only distribute released versions of bundles,  so no
> Neon build should redistribute any unreleased version of anything. 
> If a new version of something is needed for security reasons or other
> reasons, it should be released first.  And doing that in a
> maintenance train without testing the overall impact is clearly
> something we should never do again (without waving a bunch of red
> flags of warning).  And as Martin Oberhuber asks, is nothing in place
> to check for this?

I think this goes back to having proper branching to prevent things
that have problems (and meant for Oxygen) from getting into a stable
release and more thorough testing of how various plugins coexist when
installed. I could also make sure to be more explicit about where
certain milestone builds can and can't be used.

-- 
Roland Grunberg
___
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