Hi Matthias / other parties following along,

I think there are two things going on here. In M3 I removed a very small
part of Mylyn[1], as far as I understood, just the SDK for a part of Mylyn,
nothing functional. The error message you reported is not caused by that,
but instead caused by the problem of p2 not taking into consideration
"uses" directives when doing the upgrade. The error message you get is just
a more visible problem than was there since 2020-06. In 2020-06 and 2020-09
at some points within use of Mylyn a user would get failed operation with
"java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext" or similar in
their error log. So in 2020-12 the error has simply been surfaced to happen
at startup time rather than delayed at runtime.

This error message being visible to everyone doing an upgrade is bad. I
don't know your exact steps, but got them like this*.

I thought I had mitigated this all properly[2] (i.e. worked around the
Mylyn bitrotting problem in EPP) by forcing install of the required JAXB
bundles so that the p2 resolution limitation did not affect the install.

The mitigation done in [2] was supposed to be temporary, i.e until Mylyn
provided a proper fix! As Mylyn didn't by RC1, I made a slight modification
to the workaround to make it uninstallable[3]. However, that seems to have
had the unintended side-effect of causing the upgrade flow to no longer
upgrade that feature and instead on upgrade that feature is removed from
the install.

Therefore I will simply revert it [4] and we should be good to go. I have
tested this locally and will retest tomorrow from the actual build.

There will still be ways to create a bad install, but it should be
generally harder for users to hit this.

Post-mortem note - this wasn't detected probably because no one tested
doing an upgrade until you did. I have added an upgrade check to my sanity
check of releasing.md[5]. Hopefully some of the package maintainers can
conduct upgrade tests too.


* The way I get the error message you have is to start with 2020-09
committers, add download.eclipse.org/staging/2020-12 as an available
software site, check for updates and install all updates. On restart I get
the error you report. However in this case, you get a mismash of upgrades
and critically you are still running 2020-09 EPP and product. For example
you get the new PDE, but the old JDT and platform. If you try the same
steps, but disable all sites except the added staging repo, the upgrade
will fail with no remedy available error message.

As that left me in a different bad state which I don't really consider
valid I did a check for updates with the following two repos, which are
pretty close to what the final release repo composite will contain:
- https://download.eclipse.org/staging/2020-12/
-
https://ci.eclipse.org/packaging/job/simrel.epp-tycho-build/lastSuccessfulBuild/artifact/org.eclipse.epp.packages/archive/repository/
This means that everything upgrades correctly, except the epp.common
feature as mentioned above. It should work once a build containing [4] is
built in the next few hours.

[1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/172836
[2] https://www.eclipse.org/lists/epp-dev/msg06089.html
[3] https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/173324
[4] https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/173636
[5]
https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/173637/1/RELEASING.md

I trust that this will fully resolve the issue until either Mylyn is fixed
or removed from SimRel. I am very reluctant to remove Mylyn because for the
people who do like it they really love it and for them it is a big
differentiator. We need to have a separate discussion about how to save
Mylyn at some point.

Please let me know your thoughts.

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 9 Dec 2020 at 16:55, Matthias Sohn <matthias.s...@gmail.com> wrote:

> On Wed, Dec 9, 2020 at 10:24 AM Matthias Sohn <matthias.s...@gmail.com>
> wrote:
>
>> Currently still some parts of Mylyn's contribution to the simrel 2020-12
>> are disabled [1].
>> Will this be fixed soon before RC2 ends ?
>>
>> I contributed the JGit/EGit 5.10 release to simrel last night assuming
>> Mylyn would fix
>> these disabled parts of its contribution.
>>
>> If Mylyn is not able to fix this I have to respin EGit today in order to
>> remove the EGit Mylyn
>> integration which depends on org.eclipse.mylyn.commons.sdk.feature.group
>> which is
>> currently disabled in simrel.
>>
>
> I got no reaction from Mylyn, neither here nor on [1].
> Looks like they silently left the simultaneous release :-(
>
> I am running out of time to respin EGit today to remove the mylyn related
> EGit plugins (mylyn and github integrations),
> could do that tomorrow.
>
> I tried upgrading a 2020-09 Committer package with the 5.10 JGit/EGit
> build using the 2020-12 staging repo.
> Upgrade works but afterwards Mylyn views don't load properly complaining
> about the missing disabled features
> and logging the errors [2]. Manual workaround is to first uninstall the
> EGit mylyn integration in 2020-09
> and then install EGit and JGit 5.10 without the EGit mylyn integration.
>
> I could remove the mylyn and github integrations from simrel immediately
> but then upgrade from 2020-09
> would probably fail since in 2020-09 these plugins might be installed. So
> they would have to be uninstalled manually.
> For proper upgrade from older releases we would need to uninstall these
> plugins during the upgrade using p2.inf
> surgery. This requires implementing this in EGit and respinning the EGit
> release which I could tackle tomorrow.
>
> What do you think ?
>
> -Matthias
>
>
>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=564699
>>
>
> [2] org.osgi.framework.BundleException: Could not resolve module:
> org.eclipse.mylyn.github.ui [535]
>   Unresolved requirement: Require-Bundle: org.eclipse.mylyn.tasks.ui;
> bundle-version="[3.20.0,4.0.0)"
>     -> Bundle-SymbolicName: org.eclipse.mylyn.tasks.ui;
> bundle-version="3.25.2.v20200814-0512"; singleton:="true"
>        org.eclipse.mylyn.tasks.ui [331]
>          Unresolved requirement: Require-Bundle:
> org.eclipse.mylyn.commons.notifications.feed; bundle-version="1.0.0"
>            -> Bundle-SymbolicName:
> org.eclipse.mylyn.commons.notifications.feed;
> bundle-version="1.17.2.v20200813-0821"; singleton:="true"
>               org.eclipse.mylyn.commons.notifications.feed [299]
>                 No resolution report for the bundle.  Bundle was not
> resolved because of a uses constraint violation.
>   org.apache.felix.resolver.reason.ReasonException: Uses constraint
> violation. Unable to resolve resource
> org.eclipse.mylyn.commons.notifications.feed [osgi.identity;
> type="osgi.bundle"; version:Version="1.17.2.v20200813-0821";
> osgi.identity="org.eclipse.mylyn.commons.notifications.feed";
> singleton:="true"] because it is exposed to package 'javax.xml.bind' from
> resources javax.xml.bind [osgi.identity; type="osgi.bundle";
> version:Version="2.2.0.v201105210648"; osgi.identity="javax.xml.bind"] and
> jakarta.xml.bind [osgi.identity; osgi.identity="jakarta.xml.bind";
> type="osgi.bundle"; version:Version="2.3.3.v20201118-1818"] via two
> dependency chains.
>
> Chain 1:
>   org.eclipse.mylyn.commons.notifications.feed [osgi.identity;
> type="osgi.bundle"; version:Version="1.17.2.v20200813-0821";
> osgi.identity="org.eclipse.mylyn.commons.notifications.feed";
> singleton:="true"]
>     require: (&(osgi.wiring.bundle=javax.xml.bind)(bundle-version>=2.2.0))
>      |
>     provide: osgi.wiring.bundle: javax.xml.bind
>   javax.xml.bind [osgi.identity; type="osgi.bundle";
> version:Version="2.2.0.v201105210648"; osgi.identity="javax.xml.bind"]
>
> Chain 2:
>   org.eclipse.mylyn.commons.notifications.feed [osgi.identity;
> type="osgi.bundle"; version:Version="1.17.2.v20200813-0821";
> osgi.identity="org.eclipse.mylyn.commons.notifications.feed";
> singleton:="true"]
>     require:
> (&(osgi.wiring.bundle=com.sun.xml.bind)(bundle-version>=2.2.0))
>      |
>     provide: osgi.wiring.bundle;
> bundle-version:Version="2.3.3.v20201118-1818";
> osgi.wiring.bundle="com.sun.xml.bind"
>   com.sun.xml.bind [osgi.identity; osgi.identity="com.sun.xml.bind";
> type="osgi.bundle"; version:Version="2.3.3.v20201118-1818"]
>     import:
> (&(osgi.wiring.package=javax.xml.bind)(&(version>=2.3.3)(!(version>=2.3.4))))
>      |
>     export: osgi.wiring.package: javax.xml.bind
>   jakarta.xml.bind [osgi.identity; osgi.identity="jakarta.xml.bind";
> type="osgi.bundle"; version:Version="2.3.3.v20201118-1818"]
> at org.eclipse.osgi.container.Module.start(Module.java:463)
> at
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845)
> at
> org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
> at
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1838)
> at
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1779)
> at
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1743)
> at
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1665)
> at
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
> at
> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)
>
>
>
>> -Matthias
>>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to