Eclipse:如何确保插件中的jar优先于其他地方的其他版本?

时间:2023-02-05 12:32:23

I am developing an eclipse plugin which contains a specific version of Lucene. I need to generate a search index and deploy it so that it can be read by another application which uses the same version of Lucene.

我正在开发一个包含特定版本Lucene的eclipse插件。我需要生成一个搜索索引并进行部署,以便其他使用相同版本Lucene的应用程序可以读取它。

I recently upgraded eclipse to 3.4 and the search index is now not readable by the 2nd application. I see that eclipse 3.4 contains a newer version of Lucene and I am assuming that this version is used when generating the index.

我最近将eclipse升级到3.4,第二个应用程序现在无法读取搜索索引。我看到eclipse 3.4包含一个较新版本的Lucene,我假设在生成索引时使用了这个版本。

How can I determine exactly which version of Lucene is being used at the time the index is generated? My plugin classpath begins with my bundled version of Lucene so I would have expected that my version should get priority.

如何在生成索引时确切地确定使用哪个版本的Lucene?我的插件类路径以我的捆绑版Lucene开头,所以我希望我的版本应该优先。

TIA

3 个解决方案

#1


You might want to give ClassPath Checker and ClassPath Helper a try.

您可能想尝试使用ClassPath Checker和ClassPath Helper。

You may be able that way to ascertain precisely what jar are used in your development environment, in order to compare those with jars present in your deployment environment, where Luce generates the index.

您可以通过这种方式确定开发环境中使用的jar,以便将这些jar与部署环境中存在的jar进行比较,Luce生成索引。

ClasPath Checker jar conflicts:
Eclipse:如何确保插件中的jar优先于其他地方的其他版本?

ClasPath Checker jar冲突:

Classpath Helper Blocked (Obscured) Classes view:
Eclipse:如何确保插件中的jar优先于其他地方的其他版本?

Classpath Helper Blocked(Obscured)Classes视图:

#2


Seems to work now. For those of you who are interested, this is what I had to do:

似乎现在工作。对于那些感兴趣的人,这是我必须做的:

  • Removed the Lucene 1.4.3 jar from my plugin
  • 从我的插件中删除了Lucene 1.4.3 jar

  • Copied the old Lucene plugin from an older version of eclipse into version 3.4.
  • 将旧的Lucene插件从旧版本的eclipse复制到版本3.4。

  • Deleted all the dependencies in the plugin.xml wizard. Now all the Lucene plugins are visible.
  • 删除了plugin.xml向导中的所有依赖项。现在所有的Lucene插件都可见。

  • Selected version 1.4.xx and changed the properties to set a max version up to 1.5
  • 选择版本1.4.xx并更改属性以将最大版本设置为1.5

  • Added the other plugin dependencies
  • 添加了其他插件依赖项

  • Changed build path: removed old jar, added plugin dependency Lucene 1.4.3
  • 改变了构建路径:删除了旧jar,添加了插件依赖Lucene 1.4.3

  • Recalculated Run configuration. The Lucene 1.4.3 plugin was not added automatically so added it by hand.
  • 重新计算的运行配置。 Lucene 1.4.3插件没有自动添加,因此手动添加。

  • Now when the index is generated, version 1.4.3 is loaded.
  • 现在,当生成索引时,将加载版本1.4.3。

Hope this is useful to someone.

希望这对某人有用。

#3


Since you're developing an Eclipse plug-in you should look into OSGi. Eclipse plug-ins are instances of OSGi bundles and OSGi has a strong model for handling dependencies and versioning between bundles.

由于您正在开发Eclipse插件,因此您应该查看OSGi。 Eclipse插件是OSGi包的实例,OSGi有一个强大的模型来处理bundle之间的依赖关系和版本控制。

I don't know your specific code, but if was planning to use Lucene in my plug-in I'd use OSGi's 'Import-Package' or 'Require-Bundle' functionality to express the dependency; I would not include the Lucene JAR in my plug-in. If every plug-in included their own Lucene JAR, you'd waste space, but more importantly, end up with incompatible versions (like you have).

我不知道你的具体代码,但如果我计划在我的插件中使用Lucene,我会使用OSGi的'Import-Package'或'Require-Bundle'功能来表达依赖;我不会在我的插件中包含Lucene JAR。如果每个插件都包含他们自己的Lucene JAR,那么你会浪费空间,但更重要的是,最终会出现不兼容的版本(就像你一样)。

OSGI's website is not the best place to start your OSGi journey (it's good for the OSGi specifications and Peter Kriens' blog). Better to start with something like Neil Bartlett's online book.

OSGI的网站不是开始您的OSGi之旅的最佳地点(它对OSGi规范和Peter Kriens的博客有利)。最好从Neil Bartlett的在线书籍开始。

#1


You might want to give ClassPath Checker and ClassPath Helper a try.

您可能想尝试使用ClassPath Checker和ClassPath Helper。

You may be able that way to ascertain precisely what jar are used in your development environment, in order to compare those with jars present in your deployment environment, where Luce generates the index.

您可以通过这种方式确定开发环境中使用的jar,以便将这些jar与部署环境中存在的jar进行比较,Luce生成索引。

ClasPath Checker jar conflicts:
Eclipse:如何确保插件中的jar优先于其他地方的其他版本?

ClasPath Checker jar冲突:

Classpath Helper Blocked (Obscured) Classes view:
Eclipse:如何确保插件中的jar优先于其他地方的其他版本?

Classpath Helper Blocked(Obscured)Classes视图:

#2


Seems to work now. For those of you who are interested, this is what I had to do:

似乎现在工作。对于那些感兴趣的人,这是我必须做的:

  • Removed the Lucene 1.4.3 jar from my plugin
  • 从我的插件中删除了Lucene 1.4.3 jar

  • Copied the old Lucene plugin from an older version of eclipse into version 3.4.
  • 将旧的Lucene插件从旧版本的eclipse复制到版本3.4。

  • Deleted all the dependencies in the plugin.xml wizard. Now all the Lucene plugins are visible.
  • 删除了plugin.xml向导中的所有依赖项。现在所有的Lucene插件都可见。

  • Selected version 1.4.xx and changed the properties to set a max version up to 1.5
  • 选择版本1.4.xx并更改属性以将最大版本设置为1.5

  • Added the other plugin dependencies
  • 添加了其他插件依赖项

  • Changed build path: removed old jar, added plugin dependency Lucene 1.4.3
  • 改变了构建路径:删除了旧jar,添加了插件依赖Lucene 1.4.3

  • Recalculated Run configuration. The Lucene 1.4.3 plugin was not added automatically so added it by hand.
  • 重新计算的运行配置。 Lucene 1.4.3插件没有自动添加,因此手动添加。

  • Now when the index is generated, version 1.4.3 is loaded.
  • 现在,当生成索引时,将加载版本1.4.3。

Hope this is useful to someone.

希望这对某人有用。

#3


Since you're developing an Eclipse plug-in you should look into OSGi. Eclipse plug-ins are instances of OSGi bundles and OSGi has a strong model for handling dependencies and versioning between bundles.

由于您正在开发Eclipse插件,因此您应该查看OSGi。 Eclipse插件是OSGi包的实例,OSGi有一个强大的模型来处理bundle之间的依赖关系和版本控制。

I don't know your specific code, but if was planning to use Lucene in my plug-in I'd use OSGi's 'Import-Package' or 'Require-Bundle' functionality to express the dependency; I would not include the Lucene JAR in my plug-in. If every plug-in included their own Lucene JAR, you'd waste space, but more importantly, end up with incompatible versions (like you have).

我不知道你的具体代码,但如果我计划在我的插件中使用Lucene,我会使用OSGi的'Import-Package'或'Require-Bundle'功能来表达依赖;我不会在我的插件中包含Lucene JAR。如果每个插件都包含他们自己的Lucene JAR,那么你会浪费空间,但更重要的是,最终会出现不兼容的版本(就像你一样)。

OSGI's website is not the best place to start your OSGi journey (it's good for the OSGi specifications and Peter Kriens' blog). Better to start with something like Neil Bartlett's online book.

OSGI的网站不是开始您的OSGi之旅的最佳地点(它对OSGi规范和Peter Kriens的博客有利)。最好从Neil Bartlett的在线书籍开始。