I have done another respin. In this case, I rebuilt the Linux Tools plug-ins to use the older version of docker-client and its dependencies which were used in Neon.2. I have back-versioned the Docker tooling plug-ins to 2.3.0 with the current date.
I have just pushed to gerrit for Neon.3_respin branch. https://git.eclipse.org/r/#/c/95501/ If no-one objects, I will merge into the branch. Verification is already successful. -- Jeff J. On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston <jjohn...@redhat.com> wrote: > Marcel, > > Since the respin didn't fix the problem, we will try reverting the > docker-client dependency and keeping as much of the added Neon.3 > functionality as possible > in place and cutting another point release. I will let the list know when > I have something in place. > > -- Jeff J. > > On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert <daniel_meg...@ch.ibm.com> > wrote: > >> Adding eclipse.org-planning-coun...@eclipse.org to this thread. >> >> Dani >> >> >> >> From: "Dr. Marcel Bruch" <marcel.br...@codetrails.com> >> To: Cross project issues <cross-project-issues-dev@eclipse.org> >> Date: 21.04.2017 10:17 >> Subject: Re: [cross-project-issues-dev] Neon.3 Update Problems: >> To Fix and How to Fix? >> Sent by: cross-project-issues-dev-boun...@eclipse.org >> ------------------------------ >> >> >> >> Hi, >> >> I’ll briefly summarize the discussion we had at the AC yesterday: >> >> Given that we don’t know how the OSGI resolver will behave (even after >> Tom back-ported a fix to Neon) it would be preferred to just have the >> Apache HTTP*** versions in Neon.3 that were already in Neon.2. This would >> to some extend “ensure" that we are "at least as as stable as Neon.2”. This >> would require us to rollback the changes that introduced the latest version >> of HTTPClient. As far as I know this would especially affect the Docker >> Tooling. (maybe more changes than that are needed) >> >> My question to the *Docker Tooling project lead*: Is it possible to >> rollback this last minute change and postpone it to Oxygen for the sake of >> making EGit, MPC, Oomph, USS, and Code Recommenders work reliably again - >> and giving us more trust that we won’t get into trouble with Neon.3? The >> simplest solution may be to contribute the docker tooling from Neon.2 in >> Neon.3. WDYT? >> >> Marcel >> >> >> >> >> On 20 Apr 2017, at 18:54, Frederic Gurr <*frederic.g...@eclipse.org* >> <frederic.g...@eclipse.org>> wrote: >> >> I can see org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in >> /home/data/httpd/ >> *download.eclipse.org/linuxtools/update-docker-2.3.1/plugins* >> <http://download.eclipse.org/linuxtools/update-docker-2.3.1/plugins>, >> but it's definitely not in the aggregated repo. >> >> >> On 20.04.2017 18:31, Jeff Johnston wrote: >> Fred, >> >> The version of httpclient also changed in our update-docker-2.3.1 repo >> from: >> >> org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643 >> >> to: >> >> org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 >> >> Not sure why this change isn't being seen as well. >> >> -- Jeff J. >> >> >> >> On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr >> <*frederic.g...@eclipse.org* <frederic.g...@eclipse.org>< >> *mailto:frederic.g...@eclipse.org* <frederic.g...@eclipse.org>>> wrote: >> >> Thanks Jeff, >> >> I ran a SimRel aggregation build. The only change I can see in the list >> of "Non Unique Versions used in repository" is that a different version >> of org.apache.httpcomponents.httpcore is now used. Instead of >> 4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925. >> >> I compared >> >> *http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt* >> <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt> >> < >> *http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt* >> <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt> >> > >> and >> >> *https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt* >> <https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt> >> < >> *https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt* >> <https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt> >> > >> >> @All: is that the intended result? >> >> Regards, >> >> Fred >> >> >> On 19.04.2017 20:21, Jeff Johnston wrote: >> Hi Fred, >> >> I have just pushed a change to gerrit: >> *https://git.eclipse.org/r/#/c/95308/* >> <https://git.eclipse.org/r/#/c/95308/> >> <*https://git.eclipse.org/r/#/c/95308/* >> <https://git.eclipse.org/r/#/c/95308/>> >> >> I only changed the docker repository and left the other Linux Tools >> features alone >> since they were only bumped as part of the point release to fix the >> Docker Tooling plug-ins. >> >> I assume I can merge the patch if the gerrit verification is >> successful. If this is wrong, >> let me know. >> >> -- Jeff J. >> >> On Wed, Apr 19, 2017 at 1:08 PM, Frederic Gurr >> <*frederic.g...@eclipse.org* <frederic.g...@eclipse.org>< >> *mailto:frederic.g...@eclipse.org* <frederic.g...@eclipse.org>> >> <*mailto:frederic.g...@eclipse.org* <frederic.g...@eclipse.org> >> <*mailto:frederic.g...@eclipse.org* <frederic.g...@eclipse.org>>>> >> wrote: >> >> Hi, >> >> Can you provide a patch for the SimRel build (branch >> "Neon.3_respin") >> that references the new version? >> >> Regards, >> >> Fred >> >> On 19.04.2017 17:27, Jeff Johnston wrote: >> Hi Ed, >> >> Linux tools spun a 5.3.1 release which now has a 2.3.1 >> version of >> docker >> tooling. The Linux tools download site has >> update-docker-2.3.1 and >> update-docker, both which have 2.3.1 versions of the docker.core >> plug-in >> and docker feature. Not sure why you are not seeing this. >> >> -- Jeff J. >> >> On Wed, Apr 19, 2017 at 11:13 AM, Ed Merks >> <*ed.me...@gmail.com* <ed.me...@gmail.com><*mailto:ed.me...@gmail.com* >> <ed.me...@gmail.com>> >> <*mailto:ed.me...@gmail.com* <ed.me...@gmail.com>< >> *mailto:ed.me...@gmail.com* <ed.me...@gmail.com>>> >> <*mailto:ed.me...@gmail.com* <ed.me...@gmail.com>< >> *mailto:ed.me...@gmail.com* <ed.me...@gmail.com>> >> <*mailto:ed.me...@gmail.com* <ed.me...@gmail.com>< >> *mailto:ed.me...@gmail.com* <ed.me...@gmail.com>>>>> wrote: >> >> Frederic, >> >> There seem to have been no notes/minutes taken during >> the meeting: >> >> >> *https://wiki.eclipse.org/Planning_Council/April_05_2017* >> <https://wiki.eclipse.org/Planning_Council/April_05_2017> >> <*https://wiki.eclipse.org/Planning_Council/April_05_2017* >> <https://wiki.eclipse.org/Planning_Council/April_05_2017>> >> <*https://wiki.eclipse.org/Planning_Council/April_05_2017* >> <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* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>>>> >> To change your delivery options, retrieve your >> password, or >> unsubscribe from this list, visit >> >> >> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev* >> <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* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>>>> >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> >> >> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev* >> <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* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>>>> >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> >> >> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev* >> <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* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>>> >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> >> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev* >> <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* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>>> >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> >> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev* >> <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* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev* >> <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* >> <cross-project-issues-dev@eclipse.org> >> <*mailto:cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org>> >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev* >> <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* >> <cross-project-issues-dev@eclipse.org> >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev* >> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> *cross-project-issues-dev@eclipse.org* >> <cross-project-issues-dev@eclipse.org> >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev* >> <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 <+49%206151%202767092> >> Mobile: +49-179-131-7721 <+49%20179%201317721> >> *http://www.codetrails.com/* <http://www.codetrails.com/> >> >> Managing Director: Dr. Marcel Bruch >> Handelsregister: Darmstadt HRB 91940 >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> > >
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
