IMHO, the subsystem type “osgi.subsystem.feature” is a unscoped subsystem,
ideally the Export/Import packages from them will not have any effect.
For “osgi.subsystem.feature” you can play with imports/exports within the
respective Subsytem resources instead at the subsystem level.
On 29/07/15 4:46 pm, "Wouter Bancken" wrote:
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
