[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?

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@xxxxxxxxxx>>
>>>>> wrote:
>>>>>
>>>>>               Adding eclipse.org-planning-council@xxxxxxxxxxx
>>>>>               <mailto:eclipse.org-planning-council@xxxxxxxxxxx> to
>>>>> this
>>>>>               thread.
>>>>>
>>>>>               Dani
>>>>>
>>>>>
>>>>>
>>>>>               From:        "Dr. Marcel Bruch"
>>>>> <marcel.bruch@xxxxxxxxxxxxxx
>>>>>               <mailto:marcel.bruch@xxxxxxxxxxxxxx>>
>>>>>               To:        Cross project issues
>>>>>               <cross-project-issues-dev@xxxxxxxxxxx
>>>>>               <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@xxxxxxxxxxx>> 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@xxxxxxxxxxx><_mailto:frederic.gurr@xxxxxxxxxxxx
>>>>>               <mailto:frederic.gurr@xxxxxxxxxxx>>> 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@xxxxxxxxxxx><_mailto:frederic.gurr@xxxxxxxxxxxx
>>>>>               <mailto:frederic.gurr@xxxxxxxxxxx>>
>>>>>                  <_mailto:frederic.gurr@xxxxxxxxxxxx
>>>>>               <mailto:frederic.gurr@xxxxxxxxxxx>
>>>>>                 <_mailto:frederic.gurr@xxxxxxxxxxxx
>>>>>               <mailto:frederic.gurr@xxxxxxxxxxx>>>> 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@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>
>>>>>                  <_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@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>
>>>>>                  <_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@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>
>>>>>                  <_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@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>>>
>>>>>
>>>>>                  _______________________________________________
>>>>>                 cross-project-issues-dev mailing list
>>>>>                 _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>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>               _______________________________________________
>>>>>               cross-project-issues-dev mailing list_
>>>>>               __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>>
>>>>>
>>>>>                  _______________________________________________
>>>>>                 cross-project-issues-dev mailing list
>>>>>                 _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>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>               _______________________________________________
>>>>>               cross-project-issues-dev mailing list_
>>>>>               __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>
>>>>>
>>>>>               _______________________________________________
>>>>>               cross-project-issues-dev mailing list_
>>>>>               __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>
>>>>>
>>>>>               --
>>>>>               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@xxxxxxxxxxx
>>>>>               <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@xxxxxxxxxxx
>>>>>               <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@xxxxxxxxxxx
>>>>> To change your delivery options, retrieve your password, or
>>>>> unsubscribe from this list, visit
>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>>>
>>>> _______________________________________________
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or
>>>> unsubscribe from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>> _______________________________________________
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>