| P2 Director creating an inconsistent configuration that crashes after restart [message #1842157] |
Thu, 10 June 2021 15:18  |
 Elie Richa
Messages: 72
Registered: February 2016 |
Member |
|
|
Hello folks,
I encountered an odd situation this week where without making any changes to my Oomph product setup, I ended up with an inconsistent set of plugins that was not detected early by P2 Director. Only after the restart did I see major crashes as Error Log entries.
I'd like to understand what happened and how I can control my dependencies better and avoid this in the future.
Here's my product definition in the Eclipse Installer. It's based on Eclipse Modeling Tools 2020-09 + additional third-party and in-house plugins.
That step proceeds successfully. In particular I can see these plugin versions installed (this will be important later):
Installing com.google.guava [27.1.0.v20190517-1946]
Installing com.google.inject [3.0.0.v201605172100]
After the new Eclipse installation starts, Oomph asks to install org.eclipse.oomph.targlets and org.eclipse.oomph.setup.targlets:
I accept. This time Oomph installs newer versions of the Google plugins:
...
Adding repository http://vrapper.sourceforge.net/update-site/stable
Adding repository file:/Users/richa/Downloads/qgen-bls-tools-22.0w-20210606-x86_64-linux-bin
Adding repository http://download.eclipse.org/releases/2020-09
Adding repository https://qgen-p2.eu.adacore.com/qgen-dev/latest
Adding repository http://download.eclipse.org/acceleo/updates/releases/3.7
Adding repository http://download.eclipse.org/modeling/tmf/xtext/updates/releases/2.23.0
Adding repository http://download.itemis.com/updates/releases/2.1.1/
Adding repository http://download.eclipse.org/technology/epp/packages/2020-09
Adding repository http://download.eclipse.org/egit/updates
Adding repository http://download.eclipse.org/oomph/updates/milestone/latest
Calculating requirements and dependencies.
Computing prerequisite plan
Installing com.google.inject [5.0.1.v20210324-2015]
Installing com.google.guava [30.1.0.v20210127-2300]
...
This is already a bit surprising because none of the update sites I specified (logged above) contain these versions of the plugins.
So where did Oomph find com.google.guava 30.1.0 ?
How did it get access to that P2 repository if it wasn't listed in the product definition nor logged by P2 Director?
Next, after the restart, Eclipse takes a long time to start, and I see crashes in the Error Log similar to this (full error attached):
Bundle was not resolved because of a uses constraint violation.
org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.irit.xtext.blocklibrary.ide [osgi.identity; type="osgi.bundle"; version:Version="1.0.0.202106070604"; osgi.identity="org.irit.xtext.blocklibrary.ide"; singleton:="true"] because it is exposed to package 'com.google.common.base' from resources com.google.guava [osgi.identity; type="osgi.bundle"; version:Version="27.1.0.v20190517-1946"; osgi.identity="com.google.guava"] and com.google.guava [osgi.identity; osgi.identity="com.google.guava"; type="osgi.bundle"; version:Version="30.1.0.v20210127-2300"] via two dependency chains.
Chain 1:
org.irit.xtext.blocklibrary.ide [osgi.identity; type="osgi.bundle"; version:Version="1.0.0.202106070604"; osgi.identity="org.irit.xtext.blocklibrary.ide"; singleton:="true"]
require: (&(osgi.wiring.bundle=org.irit.xtext.blocklibrary)(bundle-version>=1.0.0))
|
provide: osgi.wiring.bundle: org.irit.xtext.blocklibrary
com.google.guava [osgi.identity; type="osgi.bundle"; version:Version="27.1.0.v20190517-1946"; osgi.identity="com.google.guava"]
Chain 2:
org.irit.xtext.blocklibrary.ide [osgi.identity; type="osgi.bundle"; version:Version="1.0.0.202106070604"; osgi.identity="org.irit.xtext.blocklibrary.ide"; singleton:="true"]
require: (&(osgi.wiring.bundle=org.irit.xtext.blocklibrary)(bundle-version>=1.0.0))
|
provide: osgi.wiring.bundle; bundle-version:Version="1.0.0.202106070604"; osgi.wiring.bundle="org.irit.xtext.blocklibrary"; singleton:="true"
org.eclipse.xtext.util [osgi.identity; type="osgi.bundle"; version:Version="2.23.0.v20200831-0730"; osgi.identity="org.eclipse.xtext.util"]
require: (&(osgi.wiring.bundle=com.google.inject)(bundle-version>=3.0.0))
|
provide: osgi.wiring.bundle; bundle-version:Version="5.0.1.v20210324-2015"; osgi.wiring.bundle="com.google.inject"
com.google.inject [osgi.identity; osgi.identity="com.google.inject"; type="osgi.bundle"; version:Version="5.0.1.v20210324-2015"]
import: (&(osgi.wiring.package=com.google.common.collect)(&(version>=30.1.0)(!(version>=31.0.0))))
|
export: osgi.wiring.package: com.google.common.collect; uses:=com.google.common.base
export: osgi.wiring.package=com.google.common.base
com.google.guava [osgi.identity; osgi.identity="com.google.guava"; type="osgi.bundle"; version:Version="30.1.0.v20210127-2300"]
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)
We can see that the issue is a conflict between two versions of com.google.guava, 27.1.0 and 30.1.0.
Why was this conflict not detected earlier by P2 Director before the configuration was installed?
I managed to solve the entire issue by upgrading my base Eclipse Modeling Tools version to 2021-03. But going forward, how can I avoid this issue where without changing anything in my product definition, I end up with a broken installation?
Many thanks in advance!
Elie Richa, Ph.D
Software Engineer, AdaCore
https://www.adacore.com
|
|
|
| Re: P2 Director creating an inconsistent configuration that crashes after restart [message #1842182 is a reply to message #1842157] |
Fri, 11 June 2021 05:38  |
Ed Merks
Messages: 33145
Registered: July 2009 |
Senior Member |
|
|
Yes, p2 can create installations that can have wiring problems. If I understand that problem correctly, p2 only makes sure the requirements are satisfied, but it doesn't "wire" each bundle that provides a requirement to the bundle requiring what's provided to produce a full wiring and then detect inconsistencies in that wiring. Only OSGi does that at runtime. From what I see in the above it looks to me that org.irit.xtext.blocklibrary specifically requires version 30 via "Import: (&(osgi.wiring.package=com.google.common.collect)(&(version>=30.1.0)(!(version>=31.0.0)))" so it must be providing that...
For the simultaneous release we try to avoid the overall repository containing multiple versions of bundles, especially things like Guava, because we know it causes issues like this. I think that if you add an explicit requirement like this
<?xml version="1.0" encoding="UTF-8"?>
<p2:Requirement
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:p2="http://www.eclipse.org/oomph/p2/1.0"
name="com.google.guava"/>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03246 seconds
] 
Search
Help
Register
Login
Home
