有几种方法可以在Eclipse中制定bundle依赖项。我的问题是：＆＃34;它的全部内容是什么？＆＃34;，＆＃34;为什么Eclipse使用两个不同的文件（plugin.xml，manifest.mf）？＆＃34;，＆＃34; equinox还处理Eclipse扩展机制还是只处理OSGi相关信息？＆＃34;。 据我了解，eclipse在转移到Equinox之前提供了扩展机制。扩展机制背后的想法是，开发人员可以定义精确的接口，以便在将来使用其他功能增强Eclipse RCP。这些信息存储在xml文档中＆＃34; plugin.xml＆＃34;指定提供的扩展点和实现的扩展。
另一方面，Equinox提供了功能齐全的服务，这些服务现在都可以实现，并且可以被插件（如库）使用。意味着功能已经存在，并且可以在服务方面由捆绑使用。 OSGi相关信息位于MANIFEST.MF中，通过添加这些可选信息。不使用OSGi的应用程序将不会考虑此信息，但由于信息是可选的，因此将完全正常运行。如果我错了，请告诉我。
答案 0 :(得分：3)
在Eclipse 3.0之前，Eclipse运行时有自己的模块概念和实现。 plugin.xml用于声明扩展以及声明与其他插件的依赖关系。
使用Eclipse 3.0，项目维护者决定使用OSGi来模块化Eclipse，并且Equinox诞生了。它实现了OSGi规范，该规范也进行了扩展，以提供从以前版本继承的Eclipse特性。
从那时起，每个插件都是一个OSGi包，但不一定相反。通常，每个插件和包也可以用作普通库，忽略jar中包含的元数据。但是，在运行时，插件/包通常不是很有用，因为它们依赖于Equinox / OSGi提供的基础结构。
因此，现在，plugin.xml文件只包含扩展和扩展点，OSGi运行时读取MANFIEST.MF文件，以获取 - 以及其他声明 - 依赖性信息。
Equinox项目提供了两件事：
服务也是OSGi规范的一部分。从技术上讲，服务和扩展可以用作入口点到平台/其他插件的功能中。但是，由于历史原因，我认为，大多数入口点都是以扩展点的形式提供的。
扩展点设计的一个目标是管理大量扩展，而不会降低Eclipse在启动时和运行时的性能。因此，读取扩展点和扩展名时不会激活提供它们的插件的OSGi包。激活时间尽可能晚：需要调用扩展程序提供的代码。
这会回答你的问题/确认你的假设吗？