You might want to read https://www.aqute.biz/2020/03/17/req-caps.html
<https://www.aqute.biz/2020/03/17/req-caps.html>
It is a bit of work to get your build on the level so that you can use that
model, it does require a high level on the Modularity Maturity Model[1].
However, you won't believe the benefits once you get there. On the highest
level, it takes most of the pain out of development and allows you to focus on
developing new functionality, the fun part. It is sadly our industry's best
kept secret :-(
Kind regards,
Peter Kriens
[1]: https://www.aqute.biz/appnotes/modularity-maturity-model.html
<https://www.aqute.biz/appnotes/modularity-maturity-model.html>
> On 21 Aug 2020, at 00:32, Zyle Moore <moore.z...@gmail.com> wrote:
>
> 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
> <mailto: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
> > <mailto: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 <mailto:osgi-dev@mail.osgi.org>
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > <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
