OSGi applications are composed of modules called bundles. The problem is that any reasonably sized application will have a large number of bundles (could easily be hundreds, just look at the plugins directory of your Eclipse IDE), so that you want a coarser granularity than individual bundles when managing or deploying the application.
The OSGi Service Compendium Spec contains a Deployment Admin Service, which defined deployment packages as a collection of bundles and other artifacts (such as configuration) that can be deployed, upgraded, uninstalled and so forth as a single unit.
Unfortunately, I could not find much information about Deployment Admin implementations, tooling or users.
What is the status of this service?
Does anyone have any experience, opinion or recommendation regarding Deployment Admin?
Also, Spring dm-server has the concept of application-scope collection of bundles (PAR files) and Eclipse Equinox is working on nested frameworks to address the problem, I think. How do these approaches relate to Deployment Admin?
Deployment Admin is one of those OSGi compendium services that seems to have attracted relatively little attention. Clearly there is a specification and therefore presumably a reference implementation and compliance tests. An implementation was contributed to the Apache Felix project, but seems to have sunk pretty much without trace.
I looked into Deployment Admin when designing the PAR file support in SpringSource dm Server, but the model was inappropriate for our use cases. In particular, a bundle with a given symbolic name (and any version) may not reside in two distinct Deployment Packages which are installed in the same OSGi framework.
In contrast, two PAR files installed in the same instance of dm Server may both contain a bundle with a given bundle symbolic name (and the same or different bundle version). We see this as an application scaling requirement: we didn’t want large applications to “collide” simply because their developers happened to package the same bundle. Services are also scoped by PAR files.
In dm Server 2.0 we have generalised the concept of PARs into “plans” which are files referring, by type name and version, to artifacts to be installed. A plan may be scoped (like a PAR) or unscoped and may be atomic (meaning the lifecycle of its contents is tied atomically to the lifcycle of the plan, like a PAR) or non-atomic.
Nested frameworks are also being investigated as a possible future OSGi standard to address application scoping requirements but with a rather different design point to dm Server scopes. A nested framework cannot automatically see the packages and services in its parent framework. So the model is one of isolation by default, whether that is isolation of child frameworks from each other or isolation of child and parent frameworks. dm Server scopes deliberately isolate children from each other but only isolate a child from its parent in one direction: a child can see all its parent’s packages and services.