For reasons of compatibility with an external product, I need to build a RCP application which must include 2 versions of a plugin. The plugin is org.apache.lucene which is currently 1.9.1 in eclipse 3.4. I need version 1.4.103 in order to be compatible with the other application. I should say that my RCP app was originally developed using eclipse 3.2 and after upgrading to 3.4 this problem arose.
出于与外部产品兼容的原因,我需要构建一个RCP应用程序,该应用程序必须包含2个版本的插件。插件是org.apache.lucene,目前在eclipse 3.4中是1.9.1。我需要1.4.103版本才能与其他应用程序兼容。我应该说我的RCP应用程序最初是使用eclipse 3.2开发的,在升级到3.4之后出现了这个问题。
During development and test my app worked ok. I had to add the 1.4.103 plugin by hand in the Run configuration but otherwise it ran ok.
在开发和测试期间,我的应用运行正常我必须在Run配置中手动添加1.4.103插件,否则它运行正常。
Now I am at the Build Product stage and cannot find a way to add the 2 versions of the Lucene plugin in the Configuration tab of the Product wizard. At runtime an error indicates that the 1.4.103 version of Lucene is missing.
现在我处于Build Product阶段,无法在Product向导的Configuration选项卡中找到添加Lucene插件的两个版本的方法。在运行时,错误表示缺少1.4.103版本的Lucene。
3 个解决方案
#1
Consider that, in OSGi, bundles have no concept of direct dependence between bundles.
Instead, each bundle lists the services and packages it expects to be registered by other bundles via the "Import-Package" and "Import-Service" headers.
考虑到,在OSGi中,bundle没有束之间直接依赖的概念。相反,每个捆绑包列出了其他捆绑包希望通过“Import-Package”和“Import-Service”标头注册的服务和包。
On the opposite side, a bundle lists what services and packages it plans to export via "Export-Package" and "Export-Service". Thus, there are no hard dependencies between bundle implementations. As long as some bundle provides your imported packages your bundle will be happy.
另一方面,捆绑包列出了它计划通过“Export-Package”和“Export-Service”导出的服务和包。因此,bundle实现之间没有硬依赖关系。只要某个捆绑包提供您导入的包,您的捆绑包就会很开心。
As an illustration, WTP (Web Tools Platform) has Duplicated javax.wsdl plugins:
举例来说,WTP(Web工具平台)有重复的javax.wsdl插件:
Now you should make sure you have converted your 3.2 Plugin project with the sub-menu "PDE tools" (right click on your project).
现在你应该确保你已经使用子菜单“PDE工具”(右键单击你的项目)转换了你的3.2插件项目。
Then you may define an product for your rcp application, in which you will define a configuration (target) for runtime, as opposed to a development target.
然后,您可以为rcp应用程序定义产品,在该应用程序中,您将为运行时定义配置(目标),而不是开发目标。
#2
I dug into this issue quite a bit dealing with a product that bundled BIRT, and thus inherited a requirement for the 2 different versions of javax.wsdl. After reading a lot of wiki pages, bugzilla entries, etc., I found that it was a problem in the PDE (Plug-in Development Environment) Build process. The problem has now been corrected in Eclipse 3.5. The bugzilla entry is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=265438.
我在处理捆绑BIRT的产品时涉及到这个问题,因此继承了对2个不同版本的javax.wsdl的要求。在阅读了很多wiki页面,bugzilla条目等之后,我发现它是PDE(插件开发环境)构建过程中的一个问题。现在,Eclipse 3.5中已经解决了这个问题。 bugzilla条目位于https://bugs.eclipse.org/bugs/show_bug.cgi?id=265438。
Basically, Eclipse itself allows you to specify both versions and resolves everything correctly. However, PDE Build (using the same product file) pulls only the newest version of the plug-in. Our solution for the current Eclipse 3.4 base was to forcibly copy the additional plug-in into the plugins folder of the target. This solved our problem for the time being, and we'll migrate to Eclipse 3.5 RCP base in the future to pick up the above noted bug fix.
基本上,Eclipse本身允许您指定两个版本并正确解析所有内容。但是,PDE Build(使用相同的产品文件)仅提取最新版本的插件。我们针对当前Eclipse 3.4基础的解决方案是将附加插件强制复制到目标的plugins文件夹中。这解决了我们目前的问题,我们将来会迁移到Eclipse 3.5 RCP库,以获取上述错误修复。
#3
how about to compile this plugin from source codes under another name? or write a wrapper for older plugin functions to newer?
怎么用另一个名字从源代码编译这个插件?或者为较旧的插件函数编写一个包装器?
#1
Consider that, in OSGi, bundles have no concept of direct dependence between bundles.
Instead, each bundle lists the services and packages it expects to be registered by other bundles via the "Import-Package" and "Import-Service" headers.
考虑到,在OSGi中,bundle没有束之间直接依赖的概念。相反,每个捆绑包列出了其他捆绑包希望通过“Import-Package”和“Import-Service”标头注册的服务和包。
On the opposite side, a bundle lists what services and packages it plans to export via "Export-Package" and "Export-Service". Thus, there are no hard dependencies between bundle implementations. As long as some bundle provides your imported packages your bundle will be happy.
另一方面,捆绑包列出了它计划通过“Export-Package”和“Export-Service”导出的服务和包。因此,bundle实现之间没有硬依赖关系。只要某个捆绑包提供您导入的包,您的捆绑包就会很开心。
As an illustration, WTP (Web Tools Platform) has Duplicated javax.wsdl plugins:
举例来说,WTP(Web工具平台)有重复的javax.wsdl插件:
Now you should make sure you have converted your 3.2 Plugin project with the sub-menu "PDE tools" (right click on your project).
现在你应该确保你已经使用子菜单“PDE工具”(右键单击你的项目)转换了你的3.2插件项目。
Then you may define an product for your rcp application, in which you will define a configuration (target) for runtime, as opposed to a development target.
然后,您可以为rcp应用程序定义产品,在该应用程序中,您将为运行时定义配置(目标),而不是开发目标。
#2
I dug into this issue quite a bit dealing with a product that bundled BIRT, and thus inherited a requirement for the 2 different versions of javax.wsdl. After reading a lot of wiki pages, bugzilla entries, etc., I found that it was a problem in the PDE (Plug-in Development Environment) Build process. The problem has now been corrected in Eclipse 3.5. The bugzilla entry is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=265438.
我在处理捆绑BIRT的产品时涉及到这个问题,因此继承了对2个不同版本的javax.wsdl的要求。在阅读了很多wiki页面,bugzilla条目等之后,我发现它是PDE(插件开发环境)构建过程中的一个问题。现在,Eclipse 3.5中已经解决了这个问题。 bugzilla条目位于https://bugs.eclipse.org/bugs/show_bug.cgi?id=265438。
Basically, Eclipse itself allows you to specify both versions and resolves everything correctly. However, PDE Build (using the same product file) pulls only the newest version of the plug-in. Our solution for the current Eclipse 3.4 base was to forcibly copy the additional plug-in into the plugins folder of the target. This solved our problem for the time being, and we'll migrate to Eclipse 3.5 RCP base in the future to pick up the above noted bug fix.
基本上,Eclipse本身允许您指定两个版本并正确解析所有内容。但是,PDE Build(使用相同的产品文件)仅提取最新版本的插件。我们针对当前Eclipse 3.4基础的解决方案是将附加插件强制复制到目标的plugins文件夹中。这解决了我们目前的问题,我们将来会迁移到Eclipse 3.5 RCP库,以获取上述错误修复。
#3
how about to compile this plugin from source codes under another name? or write a wrapper for older plugin functions to newer?
怎么用另一个名字从源代码编译这个插件?或者为较旧的插件函数编写一个包装器?