Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
resolver-2.0.0
-
None
-
None
Description
- Scenario
We have a bnd project where the resolver eats all the memory until eclipse dies.
After some search and investigation of the log I stumbled upon the following repeating chains it complained about:
DEBUG: Candidate permutation failed due to a conflict between imports; will try another if possible. (Uses constraint violation. Unable to resolve resource some.bundle.1 [some.bundle.1 version=1.0.0.SNAPSHOT] because it is exposed to package 'org.eclipse.swt.widgets' from resources org.eclipse.swt [org.eclipse.swt version=3.113.0.v20191204-0601] and org.eclipse.swt [org.eclipse.swt version=3.113.0.v20191204-0601] via two dependency chains.Chain 1: some.bundle.1 [some.bundle.1 version=1.0.0.SNAPSHOT] import: (osgi.wiring.package=org.eclipse.swt.widgets) | export: osgi.wiring.package: org.eclipse.swt.widgets org.eclipse.swt [org.eclipse.swt version=3.113.0.v20191204-0601]Chain 2: some.bundle.2 [some.bundle.2 version=1.0.0.SNAPSHOT] import: (&(osgi.wiring.package=some.package.1)(version>=1.3.0)(!(version>=2.0.0))) | export: osgi.wiring.package=some.package.1; uses:=org.eclipse.swt.widgets some.bundle.3 [some.bundle.3 version=1.3.0.SNAPSHOT] import: (osgi.wiring.package=org.eclipse.swt.widgets) | export: osgi.wiring.package: org.eclipse.swt.widgets org.eclipse.swt [org.eclipse.swt version=3.113.0.v20191204-0601])
(I replaced the bundle and package names. I hope I didn't screw up)
It turned out (after debugging), that org.eclipse.swt version=3.113.0.v20191204-0601 is available twice. One from a p2 repo and one as a maven artifact, that was uploaded manually. The maven upload was renamed by artifactory and had the name swt-4.14.0.jar. besides the name, the two jars are identical to the best of my knowledge.
- the issue
The two Bundles jars, that represent the exact same bundle where handled by the resolver as two separate bundles. I'm not sure if this is an actual issue or a matter of works as intended.
If it is the latter the resource location should should be part error message. Without there is no way to distinguish the jars.
If it is the former it might be a good idea to compare resources via a hash of their content (I saw something in the debugger around the resource location, that looked like a hash and was identical for both jars, but I could be mistaken).
This could be a bnd issue as well and might be related to: https://github.com/bndtools/bnd/issues/4172