Capabilities satisfying the following requirements could not be found:

Development IDE & Build
,
1

I just started to bring my DreamScreen binding to OH3. I created a new branch and “mvn clean install” runs fine. However, when I try to prepare for a Debug session Eclipse is not able to resolve a dependency. I just added the binding to pom.xml of demo.app, but not to the required modules. I click [Resolve] and already get the error. I tried multiple times, cleaned the project etc., but problem persists

Resolution failed. Capabilities satisfying the following requirements could not be found:
    [<<INITIAL>>]
      ⇒ osgi.identity: (osgi.identity=org.apache.felix.log)
    [osgi.cmpn version=7.0.0.201802012110]
      ⇒ osgi.unresolvable: (&(must.not.resolve=*)(!(must.not.resolve=*)))
    [slf4j.api version=1.7.2]
      ⇒ osgi.wiring.package: (&(osgi.wiring.package=org.slf4j.impl)(version>=1.6.0))

Bildschirmfoto 2021-04-06 um 00.06.14
Bildschirmfoto 2021-04-06 um 00.06.14631×815 90.1 KB

Any idea?

2

@wborn Maybe you have an idea?

3

Not really without seeing any code.

4

@wborn Latest code (WIP) can be found here: openhab-addons/bundles/org.openhab.binding.dreamscreen at dreamscreen_snapshot3 · markus7017/openhab-addons · GitHub

5

It works fine for me. :slight_smile: Your screenshots do show outdated dependencies. Maybe try updating your local openhab-distro clone so it has the latest changes?

Also you should not add osgi.annotation, osgi.cpmn or osgi.core to the run requirements.
Those compile time only dependencies have the “must.not.resolve” requirements as they only contain interfaces that should already be provided by the bundles that implement these interfaces at runtime.

6

@wborn I have a similar issue with the Shelly binding. 2 users reported that they are not able to update an existing 3.0 installation with a new build of my binding. In fact I use the same IDE installation for both bindings, just switching the branches. Difference: Before I started with the DreamScreen port I re-installed the IDE to get the latest code base. Could it be that some requirement definitions have changed, which now create dependency issues with older OH core versions?

7

With the latest changes the bundle requirements have changed so OSGi R7 features can be utilized (provided by Karaf 4.3.1). OSGi R7 support is one of the main Karaf 4.3 features. As a result you cannot use bundles with such requirements with OH 3.0.x or the 3.1.0 M1, M2, M3 milestones.

8

Is there a ways to go back with the current IDE installation? I didn’t explicitly defined those dependencies, I just want to start with a fresh install. Are the benefits received by new Karaf worth breaking backward compatibility?

9

You could try checking out the latest version of the main branch of openhab-distro and then add your binding again to the demo app pom.xml and app.bndrun files.

I’d say yes, without it we won’t be able to support the newer Java versions and multi-release JARs. The next Java LTS (v17) will be released in September.

10

If I understand correctly that would fix the issue that I couldn’t start it within the IDE, but the resulting jar would still not run on a 3.0/3.1M1…3 installation, correct?

11

Yes that’s right. An easy way to build a JAR compatible with those versions is to override the openHAB Core version to 3.0.1. E.g. build your 3.1.0-SNAPSHOT bundle on the command line with Maven and add the -Dohc.version=3.0.1 option. That way you can postpone creating a 3.0.x branch until it is really necessary.

2 Likes
12

I build the binding with

mvn -Dohc.version=3.0.1 clean install

but the user is still reporting this issue (we verified that he used the updated build).
details: Shelly Binding - #2099 by Daniel_O

For know I can’t create a new build, which could be installed on productive installations in the field. :sweat:

13

I tried https://github.com/markus7017/myfiles/blob/master/shelly/org.openhab.binding.shelly-3.1.0-SNAPSHOT.jar?raw=true with a 3.0.x instance and it indeed does not work.

If I build the shelly binding myself with -Dohc.version=3.0.1 it does work with a OH 3.0.1 instance. So looks like that JAR wasn’t build with that option.

1 Like
14

hmm, need to verify/double check
thanks for supporting this investigation

1 Like
15

@wborn I did a fresh IDE install and ran
“mvn clean install -Dohc.version=3.0.1”

same result

23:12:33.965 [WARN ] [org.apache.felix.fileinstall         ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.shelly-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [274]
  Unresolved requirement: Import-Package: org.osgi.framework; version="[1.9.0,2.0.0)"

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]
16

@wborn

  • I tried running “mvn clean install -Dohc.version=3.0.1” vs. “mvn -Dohc.version=3.0.1 clean install” vs. 'mvn clean install -D “ohc.version=3.0.1”`and copied target/…jar to an 3.1M3’s addons folder
  • I tried to replace ${ohc.version} in feature.xml with “3.0.1” - same result
  • If I set ohc.version to 3.0.1-SNAPSHOT in openhab-addons/pom.xml see that the Download of 3.0.1 files starts
Downloading from openhab-snapshot: https://openhab.jfrog.io/openhab/libs-snapshot/org/openhab/core/bom/org.openhab.core.bom.compile/3.0.1-SNAPSHOT/maven-metadata.xml

so speifying ohc.version on command line seems to work in general
3.0.1 means regular release/non-SNAPSHOT so that’s ok

  • I don’t see anymore a download of 3.0.1 files, but I would expect that there are no changes anymore

I’m wondering that pom.xml specifies <karaf.version>4.3.1</karaf.version>. How does that relate to ohc.version. If the new Karaf version is explicitly specified I would gues that this create the dependency to OSGi 7.

Do I need to change any file in addition to specifying -Dohc.version=3.0.1 for mvn?
What else can I check (any log output from build showing the ohc-version)?

From my understanding other developers should face the same problem when doing a fresh install of the IDE. I did nothing special related to my binding.

  • Install Eclipse, Distro+Binding projects
  • Create a new branch
  • copy updated code files to org.openhab.binding.shelly
  • run “mvn clean install -Dohc.version=3.0.1”

By the way: I use Eclipse on Mac

Wouldn’t it make sense to provide the option to setup the IDE with a specific release version, so not just “2.5.x, 3.0” as selectable streams, but “2.5.x, 3.0.1, 3.1-SNAPSHOT”. Usually there is no need for a binding developer to have the lastest floating core release, especially when architectural things change. It should be possible to create a build environment, which matches the user scenartios: 3.0.1 + a new build of a binding or 3.1-SNAPSNOT_Mx if you require latest core features for your binding (in this case it’s clear that there is a dependency on the specific core release).

17

That’s strange because it does work for me like that without making any additional changes. :thinking:

Changing the ohc.version property overrides the versions of OHC Core BOMs used. Those BOMs manage what org.osgi.framework is used. It only seems to be an issue for add-ons with org.osgi.framework imports. E.g. I could use a 3.1.0-SNAPSHOT Nest binding (which doesn’t use these imports) without any issues with OH 3.0.1.

Maybe just create a branch from 3.0.x if it doesn’t work for you?

If there is a 2.5.x stream, I think a 3.0.x stream would make sense too. But I don’t use these streams myself, I just switch between branches. :slight_smile:

18

I did some more investigation

  • using a different machine
  • delete & fresh install of the IDE
  • important shelly binding as existing maven project to the IDE
  • set git upstream to my repo
  • run mvn from the main branch with -Dohc.version=3.0.1
  • saw downloading files with /3.0.1
  • build was successful
  • copied the shelly jar to a 3.1M3 (RPi4 with Zulu 11)
    and it works!!

BUT
(same machine)

  • I switchd to the Shelly 3.1-5 branch
  • ran the same mvn command
  • again a bunch of files were downloaded (mustly checksdtyle and findbug) - why? I’m pretty sure they didn’t changed within 10minutes
  • copied to the RPi
  • and it DOESN’T work, same issue unable to resolve the component

THEN

  • I repeated procediure 1 to delete and re-install the IDE
  • run mvn with -Dohc.version=3.0.1
  • build successful, but jar doesn’t run

I’m pretty sure I could repeat it 10 times and it will fail.

It seems that the initial build process runs well, but afterwards something is downloaded/updated, which adds a dependincy to the new OSGi version.

@wborn Could you do me a favor and repeat the test on your machine, but

  • build on the main branch with 3.0.1, try jar
  • switch to shelly_snapshort3.1-5 branch
  • build again for 3.0.1 core and try again

Are there any cached files I could delete - what’s about the bundle pool?

PS: Thanks for supporting me

19

I found the problem:

  • after deleting ~/.m2/repository/org/openhab
  • and always building with -Dohc.version=3.0.1

I’m now able to run multiple builds on both machines

Strange, but @wborn thanks for your supporgt :+1:

2 Likes
20

That’s good news it finally works for you too this way! :slight_smile:
Looks like somehow some wrong content ended up in your local Maven repo.