Hi Peter, thanks for the clarification. The spec did make it clear that what is contained in the DP is treated as a unit, and that unit is very tightly contained. My thinking was that I could have a tightly contained unit for the framework, and a tightly contained unit for the resources, but this doesn't seem to be the right tool for the job.
You mentioned a resolver; what were you talking about when you referenced this? I'll ask another question, under a different subject, that gets to why I wanted to use DPs in the first place, instead of trying to un-XY-problem it. On Thu, Aug 20, 2020 at 1:53 AM Peter Kriens <peter.kri...@aqute.biz> wrote: > 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
