从 Eclipse IConfigurationElement 获取 OSGI Bundle

发布于 2024-09-05 16:57:13 字数 921 浏览 4 评论 0原文

我正在寻找实现特定扩展点的扩展，并使用以下可接受的方法来执行此操作：

IExtensionRegistry extensionRegistry = Platform.getExtensionRegistry(); if (extensionRegistry == null) { 返回模板； IConfigurationElement

[] config = extensionRegistry.getConfigurationElementsFor("com.ibm.im.launchpoint.templates.template");

然后我想获取定义包的版本。我将使用以下 API，但不推荐使用 PluginVersionIdentifier 的 API：

for (IConfigurationElement e : config) { BlueprintTemplate 模板 = new BlueprintTemplate();

IExtension declaringExtension = e.getDeclaringExtension(); PluginVersionIdentifier versionIdentifier = declaringExtension.getDeclaringPluginDescriptor().getVersionIdentifier();

我在新 API 中找不到替代方案 - 即从 IConfigurationElement 中，如何获取包的版本 id 描述符。显然，从 Bundle 中我可以使用 Bundle.getHeaders() 获取版本，获取 Bundle-Version 值 - 但我如何首先获取 Bundle ？？？ Platform.getBundle(bundleId) 是不够的，因为我可能安装了同一包的多个版本，并且我需要知道我是谁。现在我有一只鸡和一只鸡。鸡蛋的情况，我唯一的解决方案是上面不推荐使用的API。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

喵星人汪星人 2024-09-12 16:57:13

所有这些信息都基于 Eclipse 3.6：

如果您位于 osgi 环境中，您的 IContributor 将是 RegistryContributor 的实例，当然您有或没有这个问题。

RegistryContributor 为您提供了两种方法：getID() 和 getActualID()。如果这是从片段加载的，则 getID() 可能会返回主机包。 getActualID() 始终加载贡献者代表的片段/包的 ID。您可以在 BundleContext.getBundle(long id) 方法中使用此 id。这是一个片段：

Bundle bundle;
if (contributor instanceof RegistryContributor) {
  long id = Long.parseLong(((RegistryContributor) contributor).getActualId());
  Bundle thisBundle = FrameworkUtil.getBundle(getClass());
  bundle = thisBundle.getBundleContext().getBundle(id);
} else {
  bundle = Platform.getBundle(contributor.getName());          
}

我使用了一种失败方法，如果 IContributor 将来获得新的默认实现，该方法将优雅地降级为非版本感知解决方案。捆绑包 ID 对于 OSGi 实例来说是唯一的，因此它将加载正确版本的捆绑包。

All this information is based on Eclipse 3.6:

Your IContributor will be an instance of RegistryContributor if you are in the osgi environment which of course you are or you wouldn't be having this issue.

RegistryContributor gives you two methods: getID() and getActualID(). getID() may return the host bundle if this was loaded from a fragment. getActualID() always loads the id of the fragment/bundle the contributor represents. You can use this id in your BundleContext.getBundle(long id) method. Here is a snippet:

Bundle bundle;
if (contributor instanceof RegistryContributor) {
  long id = Long.parseLong(((RegistryContributor) contributor).getActualId());
  Bundle thisBundle = FrameworkUtil.getBundle(getClass());
  bundle = thisBundle.getBundleContext().getBundle(id);
} else {
  bundle = Platform.getBundle(contributor.getName());          
}

I use a fall through method that will degrade gracefully to a non-version aware solution if IContributor gets a new default implementation in the future. The bundle id is unique to an instance of OSGi so it will load the correct version of the bundle.

回复收藏 0 原文

只怪假的太真实 2024-09-12 16:57:13

我建议浏览一下 Javadoc 弃用描述，替换内容已记录在案。我找到了以下代码，但没有测试。

String contributor = e.getDeclaringExtension().getContributor().getName();
Bundle bundle = Platform.getBundle(contributor);
Version versionInfo = bundle.getVersion();

出于好奇：为什么需要获取扩展插件的版本？据我所知，扩展点机制的目标是分离扩展器的特定信息，只需要扩展（plugin.xml）或引用的代码中描述的信息。

I suggest browsing a bit the Javadoc deprecation descriptions, the replacement is documented. I found the following code, but did not test it.

String contributor = e.getDeclaringExtension().getContributor().getName();
Bundle bundle = Platform.getBundle(contributor);
Version versionInfo = bundle.getVersion();

Out of curiosity: why do you need to get the version of the extending plug-in? As far as I know, the goal of the extension point mechanism is to detach specific information about the extender, and only the information described in the extension (plugin.xml) or the referenced code is needed.

回复收藏 0 原文

~没有更多了~