[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 update problem status

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 <reckord@xxxxxxxx> 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-bounces@xxxxxxxxxxx [mailto:cross-project-
>> issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Frederic Gurr
>> Sent: Thursday, May 4, 2017 1:18 AM
>> To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
>> 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-council@xxxxxxxxxxx
>>> 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 emo@xxxxxxxxxxx to request removal.
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev