Yes, Deployment Packages may not overlap. As I recall we were never shy about
this in the spec since it was controversial?
The problems you need to solve when you have the same bundle in different DP's
with different versions were deemed too much for the hardware we were
considering in 2003. The problem with DPs is that it is too easy to create
incompatible packages, the model has a lot of error state. If you have plenty
of disk space you and you can have plenty of memory and CPU you can isolate
many of those problems. However, in a VM on an embedded device there is no such
luxury.
I also think Deployment Packages are superseded by what you can do with the
resolver. A resolver takes a set of initial requirements and calculates a
solution that takes all these problems like versions of the same bundle into
account. You then get a resolution for your platform.
For my customers, I've helped developing several management systems. The one
that works best uses the initial requirements as the configuration. When a
remote gateway needs to be updated, we calculate the actual bundles. The
gateway then calculates the differences and installs/removes/updates the
bundles accordingly.
This model is a lot less error prone.
Kind regards,
Peter Kriens
> On 20 Aug 2020, at 03:30, Zyle Moore via osgi-dev <osgi-dev@mail.osgi.org>
> wrote:
>
> Posted this at StackOverflow, but thought it might be better to ask here.
> ---
> The Deployment Admin Specification defines a way of creating Deployment
> Packages, which can contain Bundles and Resources.
>
> I wanted to use the Deployment Admin to install two types of Deployment
> Packages. The first Deployment Package would contain the "framework" of the
> program; including all infrastructure level services and bundles, like the
> Configuration Admin, Declarative Services, etc. The second Deployment Package
> would contain the "data" of the program; almost exclusively Resources to be
> processed by the Resource Processors in the framework package.
>
> In this situation, the Resource Processors would be in Customizer bundles in
> the framework package.
>
> When trying to do it this way, though, the second package is recognized as a
> foreign deployment package, and therefore can't be installed. The
> Specification, (114.5, Customizer) mentions
>
> > As a Customizer bundle is started, it should register one or more Resource
> > Processor services. These
> Resource Processor services must only be used by resources originating from
> the same Deployment
> Package. Customizer bundles must never process a resource from another
> Deployment Package,
> which must be ensured by the Deployment Admin service.
>
> To check if this was true, I looked to the Auto Configuration Specification
> (115), which specifies an Autoconf Resource Processor, which is an extension
> of the Deployment Package Specification. It specifies a Resource Processor
> implementation, and processes Resources from the Deployment Package.
>
> Based on this, if I wanted to use the Auto Configuration Specification, then
> I would seemingly need to include the Auto Configuration Bundle, and the
> Autoconf Resources within the same Deployment Package. This seems to result
> in another problem though. The Auto Configuration Bundle wouldn't be able to
> be used by another package, since a Resource Processor can only be used by
> Resources in the same package; additionally that Bundle couldn't be used by a
> separate, unrelated deployment package, because the Autoconf Bundle is
> already registered by the first package.
>
> It seems like if two Deployment Packages wanted to use Autoconf Resources, we
> would be blocked because the Resource Processor is either installed as a
> Bundle, and therefore unusable by the Deployment Admin because it is not in a
> Deployment Package, or as part of a single Deployment Package, and no other
> Deployment Package can ever use that version of that Bundle.
>
> Is my understanding correct then, that two Deployment Packages not only have
> to be separate, but also completely unrelated, to the point of not reusing
> even a single Bundle? If this is the case, then does that mean that it is
> impossible to have two Deployment Packages with Autoconf Resources; or at
> least, two packages with the same type of Resource?
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
