Hi Carsten, did any of the three scenarios previously result in an error? In other words: Was the problem reproducible for you and is that reproducible situation now fixed?
Thanks, Marcel > On 8. May 2017, at 13:34, Carsten Reckord <reck...@yatta.de> wrote: > > Hi all, > > I have tested the respin candidate with MPC, and it looks good. I've tested 3 > scenarios, using the JavaEE EPP package: > > 1. Neon.2 with Docker Tools and Oomph installed, updated to Neon.3a > -> works, and the offending HttpClient is not installed > > 2. Direct install of Neon.3a with Docker Tools and Oomph > -> works, and the offending HttpClient is not installed > > 3. Neon.3 with Docker Tools and Oomph installed, updated to Neon.3a > -> this still contains the broken HttpClient (as mentioned before). However, > at least in my tests, it looks like it was only wired to bundles requiring > only the package subset actually present in the bundle, and there were no > wiring issues through package exports that I could see. Specifically, both > USS and MPC were wired to the 4.3.6 version, so that potential conflict was > resolved properly. > > After the initial update, I ran each resulting Neon.3a instance a couple of > times with -clean and/or -initialize to see if that changed the wiring > somehow, but didn't run into problems. > > Best, > Carsten > >> -----Original Message----- >> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project- >> issues-dev-boun...@eclipse.org] On Behalf Of Frederic Gurr >> Sent: Thursday, May 4, 2017 1:18 AM >> To: Cross project issues <cross-project-issues-dev@eclipse.org> >> Subject: Re: [cross-project-issues-dev] [eclipse.org-planning-council] >> Neon.3 update problem status >> >> Hi Ed, >> >> The corresponding EPP repository can be found here: >> >> https://hudson.eclipse.org/packaging/job/neon.epp-tycho- >> build/599/artifact/org.eclipse.epp.packages/archive/repository/ >> >> Regards, >> >> Fred >> >> On 28.04.2017 10:25, Ed Merks wrote: >>> Fred, >>> >>> If someone would let me know when there is a corresponding EPP >>> repository available, I can do some further testing. With regard to >>> your specific question, if the p2.inf can specify an exact bundle >>> version to remove that's probably a good idea. And by exact I mean >>> that it would only remove the known-to-be-broken versions of these >>> bundles that no one should ever have used and no one should ever use in >>> the future. Those broken versions have never been in a "released" >>> repository, except for Neon.3. It should not remove newer versions of >>> the fixed bundles, even though those might cause the same wiring >>> problems. That being said, I think a main contributing factor to the >>> wiring problem is the constraints that were added to exclude higher >>> versions. I know for example that oomph and userstorage work fine with >>> the latest versions of these bundles but it was constrained not to use >>> to exclude the broken versions for Oomph 1.1. >>> >>> I hope that everyone who added such constraints will be sure to remove >>> them for Oxygen M7. Oomph's 1.8 contribution to Oxygen will use and >>> contribute the latest versions of those bundles... >>> >>> >>> On 27.04.2017 22:14, Frederic Gurr wrote: >>>> Open questions: >>>> - Do we need to use the uninstall command in p2.inf to remove old Http* >>>> bundles for users that already upgraded to Neon.3 and have a broken >>>> setup at the moment? How would that affect 3rd party plugins that might >>>> bring their own HttpClient version (Martin's question)? >>> >>> _______________________________________________ >>> eclipse.org-planning-council mailing list >>> eclipse.org-planning-coun...@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council >>> >>> IMPORTANT: Membership in this list is generated by processes internal to >>> the Eclipse Foundation. To be permanently removed from this list, you >>> must contact e...@eclipse.org to request removal. >> _______________________________________________ >> 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
