Hi everyone,
Using the Kura Linux emulator, I am running the Hello World example from the Kura Documentation http://eclipse.github.io/kura/dev/deploying-bundles.html#remote-target-device
I managed to run the OSGi plugin in local emulation mode, here's the output from the Kura Emulator Linux/java log.
21:14:18,036 [Component Resolve Thread] INFO HelloOsgi:15 - Bundle org.eclipse.kura.example.hello_osgi has started!
However when I try to start/stop the bundle from the console, I only manage to implement the install step. Here are some relevant outputs from the Host OSGi console after installation.
osgi> install file:/home/tihomir/workspace/kura/plugins/org.eclipse.kura.example.hello_osgi_1.0.0.201712111129.jar
Bundle id is 1020
LastModified 1513020115678
Headers Bundle-ManifestVersion = 2
Bundle-Name = Hello World Example with Logger
Bundle-RequiredExecutionEnvironment = JavaSE-1.8
Bundle-SymbolicName = org.eclipse.kura.example.hello_osgi
Bundle-Version = 1.0.0.201712111129
Import-Package = org.eclipse.osgi.framework.console;version="1.0.0",
org.osgi.framework;version="1.3.0",
org.osgi.service.component;version="1.2.2",
org.osgi.service.component.annotations;version="1.2.0";resolution:=optional,
org.osgi.util.tracker;version="1.3.1",org.4j;version="1.7.21"
Manifest-Version = 1.0
Service-Component = OSGI-INF/*.xml
Location file:/home/tihomir/workspace/kura/plugins/org.eclipse.kura.example.hello_osgi_1.0.0.201712111129.jar
State 2
Bundle 1020|Installed | 1|org.eclipse.kura.example.hello_osgi (1.0.0.201712111129)
Version 1.0.0.201712111129
RegisteredServices null
ServicesInUse null
Module osgi.identity; osgi.identity="org.eclipse.kura.example.hello_osgi"; type="osgi.bundle"; version:Version="1.0.0.201712111129" [id=1020]
SymbolicName org.eclipse.kura.example.hello_osgi
BundleContext null
BundleId 1020
osgi> ss
"Framework is launched."
id State Bundle
0 ACTIVE org.eclipse.osgi_3.12.50.v20170928-1321
Fragments=1
997 RESOLVED org.slf4j.api_1.7.2.v20121108-1250
Fragments=5, 998
998 RESOLVED org.slf4j.impl.log4j12_1.7.2.v20131105-2200
Master=997
1020 INSTALLED org.eclipse.kura.example.hello_osgi_1.0.0.201712111129
But now, when I try to activate the bundle, despite the output above showing org.slf4j is resolved, I get the following exception
osgi> start 1020
gogo: BundleException: Could not resolve module: org.eclipse.kura.example.hello_osgi [1020]
Unresolved requirement: Import-Package: org.slf4j; version="1.7.21"
I am running the emulator on Debian 9. Here's also the plugin manifest
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Hello World Example with Logger
Bundle-SymbolicName: org.eclipse.kura.example.hello_osgi
Bundle-Version: 1.0.0.qualifier
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Service-Component: OSGI-INF/*.xml
Import-Package: org.eclipse.osgi.framework.console;version="1.0.0",
org.osgi.framework;version="1.3.0",
org.osgi.service.component;version="1.2.2",
org.osgi.service.component.annotations;version="1.2.0";resolution:=optional,
org.osgi.util.tracker;version="1.3.1",
org.slf4j;version="1.7.21"
Already tried a few checks/fixes that I found here and on the Eclipse forum, but nothing worked, so any fresh suggestions are welcome.
Your
Import-Package
ranges look wrong in general. For example you have this:First: specifying the micro segment (i.e. the last segment, 21) is unnecessary. The micro version indicates bug fixes, performance improvements, documentation changes etc. None of which have any semantic impact on you as a consumer. Therefore you should just import from version
1.7
because any micro version below that will be compatible with your code.Second: you have no upper bound on your import range! This means you will import from version
1.7.21
or any higher version, up to infinity. So while you are extremely anal about the bottom end of your range, you are fantastically carefree about the upper end! You should limit the range as follows:This allows your bundle to import version 1.7 up to but NOT including version 2.0 of Slf4j (if that ever exists). This is correct because version 2 would indicate a breaking change in the Slf4j APIs.
Same advice for all your other imports:
If you use bnd or one of its derivative tools to generate your manifest, you won't have to think about any of this and it will all just be correct.