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