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

Question

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

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

如果我错了，请告诉我。

Answer 1

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

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

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

因此，现在，plugin.xml文件只包含扩展名和扩展点，MANFIEST.MF文件由OSGi运行时读取，以获得依赖信息(除其他声明外)。

Equinox项目提供了两项内容：

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

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

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

这能回答你的问题/证实你的假设吗？