Eclipse plugin Plugin.xml与OSGi规范的关系如何？

在Eclipse中，有几种方法可以表示捆绑依赖关系。我的问题是：“它是关于什么的？”，“为什么Eclipse使用两个不同的文件（plugin.xml，manifest.mf）？，“equinox是否也处理Eclipse扩展机制，还是只处理OSGi相关信息？”。 据我所知，eclipse在转移到Equinox之前提供了扩展机制吗。扩展机制背后的想法是，开发人员可以定义精确的接口，从而在将来使用附加功能增强Eclipse RCP。此信息存储在xml文档“plugin.xml”中，指定提供的扩展点和实现的扩展

另一方面，Equinox提供了功能齐全的服务，这些服务现在就可以实现，并且可以由插件（如库）使用。这意味着这些功能已经存在，并且可以由bundle在服务方面使用。通过添加这些可选信息，OSGi相关信息位于MANIFEST.MF中。不使用OSGi的应用程序将不考虑此信息，但由于该信息是可选的，因此将具有完整的功能

---

如果我错了，请告诉我。

在Eclipse3.0之前，Eclipse运行时有自己的模块概念和实现。xml被用来声明扩展以及对其他插件的依赖关系

有了Eclipse3.0，项目维护人员决定使用OSGi来模块化Eclipse，Equinox就诞生了。它实现了OSGi规范，并对其进行了扩展，以提供从以前版本继承的Eclipse特性

从那时起，每个插件都是一个OSGi包，但不一定相反。通常，每个插件和捆绑包也可以用作普通库，忽略jar中包含的元数据。然而，在运行时，插件/捆绑包通常没有用处，因为它们依赖于Equinox/OSGi提供的基础设施

因此，现在plugin.xml文件只包含扩展名和扩展点，而MANFIEST.MF文件由OSGi运行时读取，以获取依赖信息（以及其他声明）

Equinox项目提供了两件事：

• OSGi规范的实现，以及特定于Eclipse的添加
• Eclipse平台和其他基于Eclipse的项目使用的核心库

服务也是OSGi规范的一部分。从技术上讲，服务和扩展可以用作平台/其他插件功能的入口点。然而，出于历史原因，我认为大多数入口点都是以扩展点的形式提供的

扩展点设计的一个目标是在不降低Eclipse在启动和运行时的性能的情况下管理大量扩展。因此，读取扩展点和扩展时不会激活提供它们的插件的OSGi包。激活尽可能晚：当需要调用扩展提供的代码时

---

这是否回答了您的问题/证实了您的假设？

您的实际问题并不清楚。堆栈溢出是针对特定编程问题而不是广泛讨论的。扩展点由扩展点注册表管理，扩展点注册表不是Equinox的一部分。如果您觉得有答案解决了问题，请单击绿色复选标记将其标记为“已接受”。这有助于将注意力集中在仍然没有答案的老帖子上。