Section 134.14.1 step 7 defines this behavior:
Determine the Subsystem dependencies. See Determining Dependencies on page
573 for details on
determining the Subsystem's dependencies. If the dependencies cannot be
determined successfully
then an installation failure occurs and a Subsystem Exception is thrown.
Otherwise continue
to the next step.
Given that language in the specification, I don't see any way to do what
you want without a Repository service that can provide the necesary
resources in order to provision a resolvable feature A.
Tom
From: Martin Petzold <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Date: 06/23/2014 01:14 PM
Subject: Re: [osgi-dev] Resolution and Subsystem Exception with two
Feature Subsystems
Sent by: [email protected]
Hi Tom,
Am 23.06.14 19:59, schrieb Thomas Watson:
The subsystems implementation is required to auto-provision any
dependencies that a subsystem requires at subsystem installation
time. If it cannot find any resources to provision to satisfy all
the required (non-optional) dependencies then the installation of the
subsystem is required to fail. I assume if you install feature B
first then feature A is allowed to install?
thanks for your reply, the other way should work of course. However, I do
not find anything about this behaviour in the OSGi Subsystems spec. From my
point of view it does not make sense to have different resolving behaviour
of resources (bundles vs. subsystems). A Subsystem is a resource and should
resolve once its requirements are fulfilled and nothing more. How the
requirements are fulfilled should be another story.
So, how could I solve this problem? I would actually like to see a solution
without OSGi repository implementation...
a) Install subsystem A and let others be resolved (and installed?) via a
repository implementation? Don't feel well with this...
b) Is it possible to define content requirements for the root subsystem? In
this case I could add all subsystems as content requirements of the root
subsystem and then let them install (or resolve through some OSGi
repository implementation) - by the way, this would be the usual behaviour
for bundles within a subsystem and would actually be the same as my
original approach.
c) ???
Best regards,
Martin
Inactive
hide details for Martin Petzold ---06/23/2014
11:46:48
AM---Dear OSGi developers, I ran into some problem
with the
ApaMartin Petzold ---06/23/2014 11:46:48 AM---Dear
OSGi developers, I ran into some problem with the Apache Aries
Subsystem Implementation.
From: Martin Petzold <[email protected]>
To: OSGi Mail List <[email protected]>
Date: 06/23/2014 11:46 AM
Subject: [osgi-dev] Resolution and Subsystem Exception with two
Feature Subsystems
Sent by: [email protected]
Dear OSGi developers,
I ran into some problem with the Apache Aries Subsystem
Implementation.
The scenario is rather easy: lets take two subsystems A and B (type
feature). A has a requirement on a resource provided by B. All
resources
are deployed as wrapped content resources within the esa. We do not
use
any OSGi repository implementation. This is very similar to Davids
example on his blog [1], however, only one of the subsystems would
contain the shared bundle.
Why does the subsystem implementation throw a Resolution + Subsystem
Exception when I install A. Shouldn't it install A and just wait
until
it is resolved at some point in time? This would be the corresponding
behaviour for a bundle within an OSGi framework.
Background: I would like to split up the target platform into
separate
feature subsystems, e.g. core and test.
[1] http://coderthoughts.blogspot.de/2013/04/osgi-subsystems.html
Thanks and best regards,
Martin
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
