[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?



On Tue, Apr 25, 2017 at 4:10 PM, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
Ed Merks wrote:

â If nothing requires a given bundle, I would expect that bundle to be
â removed from the profile, but I don't see the problematic bundles being
â removed...

If Iâm not mistaken, the current solution with Neon.3a is reverting the problematic http bundle to the Neon.2 version; so itâs supposed to be older (lower version) than Neon.3 .

Therefore, Iâd expect that âupdatingâ from neon.3 which has the newer bundle to Neon.3a which requires the older one would probably ignore the older bundle and wire the newer one â unless something explicitly removes / uninstalls the broken Neon.3 variant.

Jeff, are you reasonably confident that a p2.inf command to uninstall the Neon.3 bundle would only perform that operation at the time the Neon.3a update is installed â and not potentially at a later time?


I certainly am not a p2.info expert. After looking at it closer, I don't think it would work since I can't specify which version of a bundle to remove. I just checked in an update to the Neon.3_respin branch. It would be helpful if someone could perform a reaggregation so others can test it and report their findings. If there are still issues, a thought would be to nail down the http reqs that docker.core was willing to use which might enable an update to remove the newer versions. My own experimenting with updating from the broken Neon.3 version to the latest version I just checked in allows the EPP for Eclipse Committers to come up without errors in the log and to run Docker Tooling successfully, but I don't know all the various error scenarios in other plug-ins that were occurring.
Â
I see some risk that 3rd party plugins which want to bring in their own http bundle would not be able to do so because weâd uninstall their payload â can we be reasonably sure that this scenario canât occur, for example by specifying an exact 4-digit version in the p2.inf to remove the broken bundle ?

IMO, the âUpdate Neon.3 to Neon.3aâ workflow is less important than fixing the âNeon.[012] -> Neon.3aâ workflow.
So if in doubt, Iâd rather not take too much risk enabling the 3 -> 3a update â

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner â Development Tools, Wind River

On 25/04/17 17:19, "cross-project-issues-dev-bounces@xxxxxxxxxxx on behalf of Ed Merks" <cross-project-issues-dev-bounces@xxxxxxxxxxx on behalf of ed.merks@xxxxxxxxx> wrote:

  Fred,

  No I didn't try that. It's much harder to try that. Oomph itself is
  broken, so I can't run setup tasks. Check for Updates finds no updates
  because I installed all the categories and their IUs don't have updated
  versions. ÂI tried explicitly installing Docker so that it would do an
  update, but that didn't not solve the wiring problem. I also running
  the p2 task in an IDE with Oomph 1.8 where I can run setup tasks
  (because Oomph's dependency on userstorage is optional in 1.8) and where
  the wiring problems also occurred so that more things got updated, but
  this also did not resolve the wiring problem. So it's not clear if
  updates to an already -broken IDE will fix that IDE; it doesn't look so
  promising, though I don't understand why that wouldn't work. ÂIf
  nothing requires a given bundle, I would expect that bundle to be
  removed from the profile, but I don't see the problematic bundles being
  removed...

  Regards,
  Ed


  On 25.04.2017 16:41, Frederic Gurr wrote:
  > Thanks Ed.
  >
  > That sounds promising. Did you also test updating a broken ELWMS with
  > the new repo?
  >
  > I'm currently trying to reproduce the error with EPP packages, but so
  > far updating a Neon.2 package to Neon.3 (with "Check for Updates") did
  > not result in a broken MPC. Not sure what I'm missing.
  >
  > Regards,
  >
  > Fred
  >
  > On 25.04.2017 16:30, Ed Merks wrote:
  >> 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 <jjohnstn@xxxxxxxxxx
  >>>>>> <mailto:jjohnstn@xxxxxxxxxx>> 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
  >>>>>> <jjohnstn@xxxxxxxxxx
  >>>>>>    <mailto:jjohnstn@xxxxxxxxxx>> 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_megert@xxxxxxxxxx <mailto:daniel_megert@xxxxxxxcom>>
  >>>>>> wrote:
  >>>>>>
  >>>>>>        Adding eclipse.org-planning-council@eclipse.org
  >>>>>>        <mailto:eclipse.org-planning-council@xxxxxxxxxxx> to
  >>>>>> this
  >>>>>>        thread.
  >>>>>>
  >>>>>>        Dani
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>        From:    "Dr. Marcel Bruch"
  >>>>>> <marcel.bruch@xxxxxxxxxxxxxx
  >>>>>>        <mailto:marcel.bruch@codetrails.com>>
  >>>>>>        To:    Cross project issues
  >>>>>>        <cross-project-issues-dev@eclipse.org
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>        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-bounces@xxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>
  >>>>>>
  >>>>>> ------------------------------------------------------------------------
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>        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@xxxxxxxxxxxx
  >>>>>>        <mailto:frederic.gurr@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@xxxxxxxxxxxx
  >>>>>>
  >>>>>> <mailto:frederic.gurr@eclipse.org><_mailto:frederic.gurr@eclipse.org_
  >>>>>>        <mailto:frederic.gurr@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/>>
  >>>>>>
  >>>>>>        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.gurr@xxxxxxxxxxxx
  >>>>>>
  >>>>>> <mailto:frederic.gurr@eclipse.org><_mailto:frederic.gurr@eclipse.org_
  >>>>>>        <mailto:frederic.gurr@eclipse.org>>
  >>>>>>         Â<_mailto:frederic.gurr@eclipse.org_
  >>>>>>        <mailto:frederic.gurr@eclipse.org>
  >>>>>>         <_mailto:frederic.gurr@eclipse.org_
  >>>>>>        <mailto:frederic.gurr@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.merks@xxxxxxxxxx
  >>>>>>        <mailto:ed.merks@xxxxxxxxx><_mailto:ed.merks@xxxxxxxxxx
  >>>>>>        <mailto:ed.merks@xxxxxxxxx>>
  >>>>>>
  >>>>>> <_mailto:ed.merks@xxxxxxxxxx<_mailto:ed.merks@xxxxxxxxxx
  >>>>>>        <mailto:ed.merks@xxxxxxxxx>>>
  >>>>>>        <_mailto:ed.merks@xxxxxxxxxx<_mailto:ed.merks@xxxxxxxxxx
  >>>>>>        <mailto:ed.merks@xxxxxxxxx>>
  >>>>>>
  >>>>>> <_mailto:ed.merks@xxxxxxxxxx<_mailto:ed.merks@xxxxxxxxxx
  >>>>>>        <mailto:ed.merks@xxxxxxxxx>>>>> 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_
  >>>>>>
  >>>>>> <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>
  >>>>>>
  >>>>>> <_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_
  >>>>>>
  >>>>>> <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_
  >>>>>>        <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>
  >>>>>>
  >>>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_
  >>>>>>        <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>>
  >>>>>>
  >>>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_
  >>>>>>        <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>
  >>>>>>
  >>>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_
  >>>>>>        <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>>>
  >>>>>>
  >>>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_
  >>>>>>        <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>
  >>>>>>
  >>>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_
  >>>>>>        <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>>
  >>>>>>
  >>>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_
  >>>>>>        <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>
  >>>>>>
  >>>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_
  >>>>>>
  >>>>>> <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 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 they are in a repository somehow,
  >>>>>>         Âhow are
  >>>>>>         Âthey
  >>>>>>         Âcategorized? It's hard to get them in and once you
  >>>>>>         Âdo, they're
  >>>>>>         Âcategorized poorly. The next question is, how do
  >>>>>> they end
  >>>>>>         Âup in the
  >>>>>>         Ârelease train, if the projects that need them don't
  >>>>>>         Âcontribute them?
  >>>>>>         ÂDirectly from Orbit you say? But which ones
  >>>>>> should be
  >>>>>>         Âpulled in from
  >>>>>>         ÂOrbit and how is that discovered? ÂAre those the
  >>>>>> ones the
  >>>>>>         Âprojects have
  >>>>>>         Âtested against? Then there is the question of
  >>>>>> whether an
  >>>>>>         Âinstallation is
  >>>>>>         Âdeterministic if the bundle version isn't pinned?
  >>>>>>         ÂIt's not;
  >>>>>>         Âit will
  >>>>>>         Âdepend on what's in the repos that are available at
  >>>>>>         Âresolve
  >>>>>>         Âtime. But
  >>>>>>         ÂGunnar argues that even packages are not
  >>>>>> deterministic,
  >>>>>>         Âwhich I think is
  >>>>>>         Âfalse: if the feature pins the bundle version and the
  >>>>>>         Âpackage requires
  >>>>>>         Âthe feature, then the pinned bundle is definitely in
  >>>>>> that
  >>>>>>         Âpackage. But
  >>>>>>         Âregardless, Gunnar's important point is that the
  >>>>>> runtime
  >>>>>>         Âwiring seems
  >>>>>>         Âkind of non-determinstic, and while uses constraints
  >>>>>> might
  >>>>>>         Âhelp, who the
  >>>>>>         Âheck understands those well, what tooling produces it
  >>>>>>         Âcorrectly for us,
  >>>>>>         Âis that nicely integrated in PDE, and will it be
  >>>>>> properly
  >>>>>>         Âmaintained (in
  >>>>>>         Âcontrast to lower bound constraints which you can
  >>>>>> pretty
  >>>>>>         Âexpect will
  >>>>>>         Âremain on whatever stale version they were
  >>>>>> initially set
  >>>>>>         Âto). This may
  >>>>>>         Âwell be the right direction in which to go, but
  >>>>>> getting
  >>>>>>         Âthere isn't
  >>>>>>         Âgoing to be even half the fun...
  >>>>>>
  >>>>>>         Regards,
  >>>>>>         Ed
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>         _______________________________________________
  >>>>>>         cross-project-issues-dev mailing list
  >>>>>>         _cross-project-issues-dev@eclipse.org_
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>>
  >>>>>>         ÂTo change your delivery options, retrieve your
  >>>>>>         Âpassword, or
  >>>>>>         Âunsubscribe from this list, visit
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>> _https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>>
  >>>>>>
  >>>>>>         Â_______________________________________________
  >>>>>>         cross-project-issues-dev mailing list
  >>>>>>         _cross-project-issues-dev@eclipse.org_
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>>
  >>>>>>         ÂTo change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>         Âunsubscribe from this list, visit
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>> _https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>>
  >>>>>>
  >>>>>>
  >>>>>>         _______________________________________________
  >>>>>>         cross-project-issues-dev mailing list
  >>>>>>         _cross-project-issues-dev@eclipse.org_
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>>
  >>>>>>         ÂTo change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>         unsubscribe from this list, visit
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>> _https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>        _______________________________________________
  >>>>>>        cross-project-issues-dev mailing list_
  >>>>>>        __cross-project-issues-dev@eclipse.org_
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
  >>>>>>        To change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>         Âunsubscribe from this list, visit
  >>>>>>
  >>>>>>
  >>>>>> _https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
  >>>>>>
  >>>>>>         Â_______________________________________________
  >>>>>>         cross-project-issues-dev mailing list
  >>>>>>         _cross-project-issues-dev@eclipse.org_
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
  >>>>>>         ÂTo change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>         unsubscribe from this list, visit
  >>>>>>
  >>>>>>
  >>>>>> _https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>        _______________________________________________
  >>>>>>        cross-project-issues-dev mailing list_
  >>>>>>        __cross-project-issues-dev@eclipse.org_
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         Â<_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>        To change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>         Âunsubscribe from this list, visit
  >>>>>>
  >>>>>> _https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>         Â_______________________________________________
  >>>>>>         cross-project-issues-dev mailing list
  >>>>>>         _cross-project-issues-dev@eclipse.org_
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>         <_mailto:cross-project-issues-dev@xxxxxxxxxxxx
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
  >>>>>>         To change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>         unsubscribe from this list, visit
  >>>>>>
  >>>>>> _https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>        _______________________________________________
  >>>>>>        cross-project-issues-dev mailing list_
  >>>>>>        __cross-project-issues-dev@eclipse.org_
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>        To change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>        unsubscribe from this list, visit_
  >>>>>>
  >>>>>> __https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>>        _______________________________________________
  >>>>>>        cross-project-issues-dev mailing list_
  >>>>>>        __cross-project-issues-dev@eclipse.org_
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>        To change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>        unsubscribe from this list, visit_
  >>>>>>
  >>>>>> __https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
  >>>>>>
  >>>>>> <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 <tel:+49%206151%202767092>
  >>>>>>        Mobile: +49-179-131-7721 <tel:+49%20179%201317721>_
  >>>>>>        __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
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>        To change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>        unsubscribe from this list, visit
  >>>>>>
  >>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>        _______________________________________________
  >>>>>>        cross-project-issues-dev mailing list
  >>>>>>        cross-project-issues-dev@eclipse.org
  >>>>>>        <mailto:cross-project-issues-dev@xxxxxxxxxxx>
  >>>>>>        To change your delivery options, retrieve your
  >>>>>> password, or
  >>>>>>        unsubscribe from this list, visit
  >>>>>>
  >>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  >>>>>>
  >>>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>> _______________________________________________
  >>>>>> 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
  >>>>>>
  >>>>> _______________________________________________
  >>>>> 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
  >>>> _______________________________________________
  >>>> 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
  >>>>
  >>> _______________________________________________
  >>> 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
  >> _______________________________________________
  >> 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
  >>
  > _______________________________________________
  > 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

  _______________________________________________
  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


_______________________________________________
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