Eclipse Language Server cannot be resolved because of a uses constraint violation

[rbaradari]

After installing STS4 from the Eclipse Market Place I run into the following FrameworkEvent error on startup:

org.osgi.framework.BundleException: Could not resolve module: org.springframework.tooling.boot.ls [1312]
  Bundle was not resolved because of a uses constraint violation.
  org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.springframework.tooling.boot.ls [osgi.identity; type="osgi.bundle"; version:Version="1.9.0.201907120625"; osgi.identity="org.springframework.tooling.boot.ls"; singleton:="true"] because it is exposed to package 'com.google.common.base' from resources com.google.guava [osgi.identity; type="osgi.bundle"; version:Version="21.0.0.v20170206-1425"; osgi.identity="com.google.guava"] and com.google.guava [osgi.identity; type="osgi.bundle"; version:Version="27.1.0.v20190517-1946"; osgi.identity="com.google.guava"] via two dependency chains.

Chain 1:
  org.springframework.tooling.boot.ls [osgi.identity; type="osgi.bundle"; version:Version="1.9.0.201907120625"; osgi.identity="org.springframework.tooling.boot.ls"; singleton:="true"]
    require: (osgi.wiring.bundle=org.eclipse.xtext.xbase.lib)
     |
    provide: osgi.wiring.bundle: org.eclipse.xtext.xbase.lib
  com.google.guava [osgi.identity; type="osgi.bundle"; version:Version="21.0.0.v20170206-1425"; osgi.identity="com.google.guava"]

Chain 2:
  org.springframework.tooling.boot.ls [osgi.identity; type="osgi.bundle"; version:Version="1.9.0.201907120625"; osgi.identity="org.springframework.tooling.boot.ls"; singleton:="true"]
    require: (osgi.wiring.bundle=org.springsource.ide.eclipse.commons.livexp)
     |
    provide: osgi.wiring.bundle; bundle-version:Version="3.9.10.201906242213-CI-B472"; osgi.wiring.bundle="org.springsource.ide.eclipse.commons.livexp"
  org.springsource.ide.eclipse.commons.livexp [osgi.identity; type="osgi.bundle"; version:Version="3.9.10.201906242213-CI-B472"; osgi.identity="org.springsource.ide.eclipse.commons.livexp"]
    require: (osgi.wiring.bundle=com.google.guava)
     |
    provide: osgi.wiring.bundle: com.google.guava
  com.google.guava [osgi.identity; type="osgi.bundle"; version:Version="27.1.0.v20190517-1946"; osgi.identity="com.google.guava"]
	at org.eclipse.osgi.container.Module.start(Module.java:457)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$1.run(ModuleContainer.java:1820)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$2$1.execute(EquinoxContainerAdaptor.java:150)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1813)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1769)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1735)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1661)
	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)

I am using
Eclipse IDE for Enterprise Java Developers.
Version: 2019-06 (4.12.0)
Build id: 20190614-1200

With a jdk1.8.0_192.

[kdvolder]

It installs and works fine for me. Whenever we get errors from osgi like this, it's usually a good idea to try and start STS/eclipse with the '-clean' option. If osgi is in a confused state this often resolves the issue, so can you give that a try. If that doesn't resolve the issue we will have to take a deeper look. But please give the -clean option a try first.

[kdvolder]

Did take a quick look and the error suggests that livexp bundle is picking up a newer version of guava while xtext.base is explicitly requesting an older one. The way I understand it, osgi should be able to resolve this issue by resolving the older bundle also for livexp (since livexp bundle doesn't explicitly require the newer version). So all the more reason to give the '-clean' option a try as this will make osgi re-resolve all dependencies. I beleave often times this kind of issue is the result of osgi caching bits of old bundle resolutions and not considering all of the possibilities.

[rbaradari]

Thank you @kdvolder for the hint. I gave -clean a try but the problem persists.
Is there any way to debug this or collect extended information?

[kdvolder]

Is there any way to debug this or collect extended information?

The error itself is actually fairly precise as to what the problem is. Not so clear as to why it arises.

We could probably just 'solve it' right now by adding an explicit version constraint in livexp bundle so that it explicitly requests the same version as xtext.base.

I'll probably do that anyway... The only potential problem I anticipate with doing that right now would be that it is likely to break again in the future (when xtext.base upgrades their guava bundle to the newer version).

So before moving on doing this I'd like to figure out why it is a problem for you and not for me.

In my STS installation which I created by using "Eclipse for Java Developers" and then installing STS 4 from marketplace... In the result of that... I only see one guava bundle (we can find all the installed plugins from "Help >> About Eclipse >> Installation Details >> Plugins") . I would like to figure out somehow what it is that you installed exactly that pulled in the newer guava. So... questions...

1. Did you start from "Eclipse for Java Developers" too? Or did you start from another Eclipse "Distribution".
2. Did you install other stuff into your Eclipse besides STS?

[rbaradari]

I played around with the plugins to trigger the resolution error and found a small set that triggers it.

These are the steps to reproduce it on my machine:

• Install "Eclipse IDE for Java Enterprise Developers" (Latest Release 2019-06) using the eclipse installer
• Using the Marketplace update Buildship (this step is somewhat strange as you need to search for Buildship, then click on "Install" and finally being on the "Installed" tab click on "Update")
• Using the Marketplace install STS4 (4.3.1 Release) (all features)
• Using the Marketplace search for and install "JBoss Tools 4.12.0.Final" (all features)

I think only a subset of the JBoss features is the culprit but I couldn't figure out which.
Updating the buildship plugin was essential to trigger the error in my installation.

[kdvolder]

Reproduced it using the last set of instructions. Thanks!

[kdvolder]

I added the extra version constraint to our livexp bundle pinning it to guava version 21.x.x and that indeed seems to 'solve' the issue.

I am actually a bit confused as to how that's really possible. As far as I know it is not possible to add more contraints to an already overconstrained problem and thereby make it solvable. Yet that seems to be what's happening.

What I was expecting instead was that adding the explicit constraint would give me a different error. I was hoping that error would explain why it couldn't explicitly bind to that older version (i.e. something else explicitly forcing the newer version to be used).

[kdvolder]

Since I am suspecting this might be a bug in Eclipse OSGI implementation, I raised this Eclipse bug here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=549431

Before adding a version contraint to our bundle, let's wait and see what they say.

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

Adding Martin as owner of this ticket. When he is back from vacation he can have a look and provide some much needed expertise around OSGI related problems.

I am not convinced just adding a bundle constraint is the right solution.

[spring-projects-issues]

(comment in Pivotal Tracker added by Martin Lippert:)

I looked into this and removed the require-bundle dependency on the xtext.lib bundle, that causes too tight coupling to a specific version of guava. Then I also changed our dependencies on guava towards proper import-package definitions in the com.google.common... packages that we use in those bundles (livexp, boot.ls, etc.).

That solves the issue and allows the OSGi resolver to find a wiring that fits all the needs here. I checked this by following the steps to reproduce the issue described in the issue, with the exception of using the nightly CI p2 repo for the STS4 bits in order to get by fixes instead of the latest release on the marketplace. Works now.

[kdvolder]

Thanks @martinlippert great you found a better solution to this.

I am wondering, what is your opinion on the Eclipse bugzilla (https://bugs.eclipse.org/bugs/show_bug.cgi?id=549431)? Do you think it is a bug in osgi? Haven't had any response/feedback on the ticket since I raised it.

[martinlippert]

I've come across a wide variety of those OSGi resolving issues in the past and there was always a good reason for the resolver to wire the bundles in the way it happened. Sometimes it is hard to find out why that specific wiring was chosen and this is the most complicated part for me when investigating those issues. I wish there would be some interactive way to talk to the resolver and ask questions like: "if you would wire this bundle is this specific way, what would happen?"

The diag command gives you a good first indication where to look for the issues and running a runtime workbench might help, too, where you can easily experiment with certain bundles in certain versions being there or not.

But beyond that, I would have no idea what to do about the bug item that you raised at Eclipse, to be honest... ;-)

[kdvolder]

Well, TBH, I am also not certain its a bug. I really don't understand enough about how it is supposed to work to be able assert that the actual observed behavior is a bug or just 'normal'.