[
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 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@eclipse.org_
> <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@eclipse.org_
> <mailto:frederic.gurr@xxxxxxxxxxx><_mailto:frederic.gurr@eclipse.org_
> <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@eclipse.org_
> <mailto:frederic.gurr@xxxxxxxxxxx><_mailto:frederic.gurr@eclipse.org_
> <mailto:frederic.gurr@xxxxxxxxxxx>>
> <_mailto:frederic.gurr@eclipse.org_
> <mailto:frederic.gurr@xxxxxxxxxxx>
> <_mailto:frederic.gurr@eclipse.org_
> <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@gmail.com_
> <mailto:ed.merks@xxxxxxxxx><_mailto:ed.merks@gmail.com_
> <mailto:ed.merks@xxxxxxxxx>>
> <_mailto:ed.merks@gmail.com_<_mailto:ed.merks@gmail.com_
> <mailto:ed.merks@xxxxxxxxx>>>
> <_mailto:ed.merks@gmail.com_<_mailto:ed.merks@gmail.com_
> <mailto:ed.merks@xxxxxxxxx>>
> <_mailto:ed.merks@gmail.com_<_mailto:ed.merks@gmail.com_
> <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@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto: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>
>
> <_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@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto: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>
>
> <_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@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto: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>
>
> <_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@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto: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>
>
> <_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@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> <_mailto:cross-project-issues-dev@eclipse.org_
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> <_mailto: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>
>
> <_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@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>
>
> <_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@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>
>
> <_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@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
>