Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-dev] [cross-project-issues-dev] Mylyn participation in 2020-12
On Thu, Dec 10, 2020 at 2:55 AM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
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.

yep, I tried the same steps
 
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:
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.

[2] https://www.eclipse.org/lists/epp-dev/msg06089.html

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.sohn@xxxxxxxxx> wrote:
On Wed, Dec 9, 2020 at 10:24 AM Matthias Sohn <matthias.sohn@xxxxxxxxx> 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
 

[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@xxxxxxxxxxx
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top