OSGi 应用程序由称为捆绑包的模块组成。问题是任何大小合理的应用程序都会有大量的包（可能很容易有数百个，只需查看 Eclipse IDE 的插件目录），因此在管理或部署应用程序时，您需要比单个包更粗的粒度。
OSGi 服务纲要规范包含一个部署管理服务，它将部署包定义为捆绑包和其他工件（例如配置）的集合，可以作为一个单元进行部署、升级、卸载等。
很遗憾，我找不到有关部署管理实施、工具或用户的太多信息。
这项服务的状态如何？ 有人对部署管理员有任何经验、意见或建议吗？
此外，我认为 Spring dm-server 具有应用程序范围的捆绑包（PAR 文件）集合的概念，并且 Eclipse Equinox 正在开发嵌套框架来解决该问题。这些方法与部署管理有什么关系？
【问题讨论】：
Deployment Admin 是那些似乎很少引起注意的 OSGi 纲要服务之一。显然有一个规范，因此可能是一个参考实现和一致性测试。为 Apache Felix 项目贡献了一个实现，但似乎已经沉没了。
我在 SpringSource dm Server 中设计 PAR 文件支持时研究了 Deployment Admin，但该模型不适合我们的用例。特别是，具有给定符号名称（和任何版本）的包可能不会驻留在安装在同一 OSGi 框架中的两个不同部署包中。
相比之下，安装在同一 dm 服务器实例中的两个 PAR 文件可能都包含具有给定包符号名称的包（以及相同或不同的包版本）。我们将此视为应用程序扩展要求：我们不希望大型应用程序仅仅因为它们的开发人员碰巧打包了相同的包而“冲突”。服务也由 PAR 文件限定。
在 dm Server 2.0 中，我们将 PAR 的概念推广到“计划”中，这些计划是通过类型名称和版本引用要安装的工件的文件。计划可能是有范围的（如 PAR）或无范围的，并且可能是原子的（意味着其内容的生命周期以原子方式与计划的生命周期相关联，如 PAR）或非原子的。
嵌套框架也正在被研究作为未来可能的 OSGi 标准，以解决应用程序范围的要求，但与 dm 服务器范围的设计点完全不同。嵌套框架无法自动查看其父框架中的包和服务。因此该模型默认是一种隔离，无论是子框架彼此隔离还是子框架和父框架隔离。 dm 服务器范围故意将子级彼此隔离，但仅在一个方向上将子级与其父级隔离：子级可以看到其所有父级的包和服务。
【讨论】：
您可能有兴趣知道Apache Ace（目前处于孵化和加速阶段）可以为部署管理员动态生成部署包，并使用（默认情况下，在配置到 OSGi 目标时）Felix 的部署管理员。
由于该网站正在开发中：Apache Ace 是一个软件分发框架，允许您集中管理和分发软件组件、配置数据和其他工件到目标系统。它是使用 OSGi 和 可以部署在不同的拓扑中。目标系统通常也基于 OSGi，但并非必须如此。
【讨论】：