这个问题是为那些非常熟悉 OSGI 和现有开发路线图的人准备的。我在 Eclipse/Equinox 上长大，并且发现扩展点框架在构建可扩展软件时非常宝贵，因为它能够通过构建允许扩展点从 java 代码中使用的模式来创建丰富的 xml 元数据带有设计时 xml 验证的 plugin.xml。这与用于定义和使用扩展点的 PDE Eclipse 工具相结合是我最喜欢的 Equinox 特性之一。
我想我已经在几乎所有我能想到的上下文中使用了扩展点，从扩展 ECore 包的 Equinox 服务器端模式以映射到休眠模式，到建模 web.xml 扩展点，允许模块化 Web 应用程序开发，其中每个插件都有能力为基于扩展生成的单个 web.xml 文件做出贡献。我喜欢以类似的方式将 JSF 配置文件移植到单个扩展点，从而允许插件贡献托管 bean，并且在模块化 Web 应用程序开发的世界中，我认为扩展点是解决丑陋战争解耦挑战的绝佳解决方案。除了替代框架如果您查看 Eclipse UI，很难想象没有扩展点的生活，但我
我最大的抱怨是缺少一个可选的基于 xml 的丰富元数据层，用于创建诸如“服务点”（因为缺少更好的词）之类的东西，它使用 xml 模式来定义服务接口中定义的方法调用的 xml 表示允许诸如“服务扩展”之类的东西在 xml 中而不是在代码中使用 OSGI 服务，从而使您的开发更加灵活和易于维护。
我不知道这是否是向 OSGI 服务提供更高级别元数据层的最佳方法，但它是一个很好的例子，因为它显示了使 OSGI 服务合同比具有用于服务消费的 xml 范式的 Java 接口更智能的好处不仅仅是服务绑定。使用上面所有的样板代码，用于注入服务或获取服务引用，然后调用 Java 代码中的方法来做一些简单的事情，比如在 HttpService 上注册一个 http 上下文，都可以在 xml 中完成。更进一步，使用纯 OSGI 服务在富客户端应用程序（如今天的 eclipse 中的扩展点）或在一个服务点可以实现为具有唯一 ID、url 映射和控制器的可扩展 Web 应用程序定义一个标准容器，在同一框架中，其他服务点允许其他捆绑包使用相对索引顺序和链接向主菜单添加菜单选项卡等内容对位于包中的 jsp 页面的引用。Web.xml 可以成为 http 服务中的服务点，允许包通过 web.xml“服务点”的“服务扩展”贡献 servlet 映射或过滤器
我并不是建议我们将扩展点框架移植到 OSGI 中，而是遵循相同的精神，即为声明性 OSGI 服务提供基于 xml 的元数据层，允许服务将其服务接口中包含的方法调用公开为“服务点”它被定义为其他声明性服务或捆绑包可以通过“服务扩展”使用的 xml 模式。我喜欢 Eclipse 扩展点的地方在于它很容易添加扩展，您可以根据捆绑类路径获得可用扩展点的漂亮对话框，并且使用 PDE 工具，扩展 UI 会根据目标扩展的架构动态呈现观点。有了这个 xml 元数据层，bundle 开发人员可以将 OSGI 服务方法公开为“服务点” 我们可以为 OSGI 服务遵循相同的模式，例如 MANIFEST 编辑器可以有一个名为“服务扩展”的选项卡，当我单击“添加”时，我会根据我的包类路径得到一个包含所有可用服务点的对话框可以使用 PDE 工具，并且像 PDE 工具一样，创建新的“服务扩展”的 UI 将围绕与“服务点”关联的模式构建。在激活我的包期间，它被转换为服务点定义的方法调用。将围绕与“服务点”关联的模式构建。在激活我的包期间，它被转换为服务点定义的方法调用。将围绕与“服务点”关联的模式构建。在激活我的包期间，它被转换为服务点定义的方法调用。
这就是我想使用 OSGI 服务的方式！我们在 Eclipse 中看到的所有简洁的 UI 框架，例如 UI 贡献或项目性质构建器、资源侦听器、您命名的编辑器贡献，都可以使用 OSGI 服务和用于包装服务方法调用的丰富 xml 元数据层以类似的方式构建和扩展进入“服务点”和作为“服务扩展”的实际调用。所以我哭泣的请求是向我展示今天在 OSGI 中提供此功能的东西！如果你什么都不知道，那么你有什么理由支持或反对这种方法，即采用 eclipse 扩展点的优点并在 OSGI 声明式服务模型中构建类似的东西，让我们在普通的 OSGI 中享受更容易和更好的可扩展性！- 邓肯·克雷布斯