Dear,
We are having an issue trying to resolve fragment bundles in a subsystem.
We created a *subsystem* (esa) with the following content (SUBSYSTEM.MF):
Subsystem-Content:
be.aca.test-service-fragment;type="osgi.fragment";version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]";start-order:="1",
be.aca.test-service;version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]";start-order:="2"
Subsystem-Type:
osgi.subsystem.feature
The *fragment* contains the following import packages:
Fragment-Host:
be.aca.test-service
Import-Package:
be.aca.subsystem.test_service.api;version="[1.0,2)",
be.aca.test-service
The *bundle* contains the following import and export packages:
Export-Package:
be.aca.subsystem.test_service.api;uses:="be.aca.subsystem.test_service.internal";version="1.0.1.SNAPSHOT",
be.aca.subsystem.test_service.internal;version="1.0.1.SNAPSHOT"
be.aca.subsystem.test_component";version="1.0.1.SNAPSHOT"
Import-Package:
be.aca.subsystem.test_component;version="[1.0,2)",
be.aca.subsystem.test_service.api;version="[1.0,2)"
The current Aries implementation is not able to find the capability for the
fragment. The SubsystemResource will first look in the SystemRepository and
next in the LocalRepository. This LocalRepository should be able to find
the fragment but it can not. We tracked this down to
BundleResource.computeOsgiIdentityCapability which calls a constructor of
OsgiIdentityCapability that manually sets the type to osgi-bundle (while it
should be fragment in this case). Therefore the requirement and the
capability do not match because of the different type.
Since the LocalRepository can not find the capability, the Aries
implementation will delegate it to our own custom repository which will
then find the correct capability in the esa. However due to the import and
export statements, our custom repository will also provide the other
packages from the test-service bundle.
Next, it will try to resolve the test-service bundle. As always it will
first look in the SystemRepository and next in the LocalRepository. The
LocalRepository will be able to find the capabilities. At this point, the
following uses constraint violation occurs:
Caused by: org.osgi.service.resolver.ResolutionException: Uses constraint
violation. Unable to resolve resource be.aca.test-service
[jar:file:/Users/wouter/Projects/common/osgi-subsystem-support/runner/directory-repository/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa!/test-service-1.0.1-SNAPSHOT.jar]
because it exports package 'be.aca.subsystem.test_service.internal' and is
also exposed to it from resource be.aca.test-service
[/var/folders/25/w0q5j_mn4l1771mbxtg6yhhm0000gn/T/inputStreamExtract3569880077784275121.zip/test-service-1.0.1-SNAPSHOT.jar]
via the following dependency chain:
be.aca.test-service
[jar:file:/Users/wouter/Projects/common/osgi-subsystem-support/runner/directory-repository/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa!/test-service-1.0.1-SNAPSHOT.jar]
import:
(&(osgi.wiring.package=be.aca.subsystem.test_service.api)(&(version>=1.0.0)(!(version>=2.0.0))))
|
export: osgi.wiring.package: be.aca.subsystem.test_service.api;
uses:=be.aca.subsystem.test_service.internal
export: osgi.wiring.package=be.aca.subsystem.test_service.internal
be.aca.test-service
[/var/folders/25/w0q5j_mn4l1771mbxtg6yhhm0000gn/T/inputStreamExtract3569880077784275121.zip/test-service-1.0.1-SNAPSHOT.jar]
We think that this issue will be resolved if the LocalRepository would be
able to find fragments since the LocalRepository will then be able to
handle all requirements. Our custom repository would never be called.
Is it a known issue that the BundleResource can not distinguish between
bundles and fragments? Or was there a reason to fix the type to "bundle"?
Best regards,
Wouter Bancken
Solution Engineer
