Eclipse中许多事情需要或使用类路径，例如Java项目、JUnit和服务器启动、Hibernate控制台等。对于这些，类路径容器比强制用户单独选择所需（可能很长的）jar文件列表要方便得多。类路径容器允许插件提供商自动创建可以一次性添加和删除的一组jar文件，简单高效。

遗憾的是，多年来我注意到许多插件创建了所谓的“自我审查的类路径容器”，这造成的麻烦比解决的问题还多。

让我们以我们不得不修复的JBoss Developer Studio的最新示例为例，即Drools插件类路径容器。

此截图显示了Drools插件早期版本提供的默认类路径容器。请注意，所有jar文件都指向Drools插件内部的固定位置（.cp\lib），这就是我所说的自我审查的类路径容器。

优点

首先，让我们看看为什么许多插件似乎都这样做。只有一个“好”理由来使用自我审查的类路径容器。那就是减少设置时间，因为不需要单独的配置来定义运行时/一系列jar文件的位置。有了自我审查的类路径容器，Drools插件可以“开箱即用”提供运行Drools项目，无需其他插件/项目的任何知识和影响。这是好事，对吧？嗯...

缺点

我不喜欢这个自我审查的理由是什么？难道我不希望用户尽可能地轻松开始，而无需考虑项目有哪些依赖项这样的细节吗？

当然，我希望用户能够尽可能轻松地开始他们的工作，但任何开发者实际上都应该关心或至少对项目有哪些依赖项有一些意识——如果我们使用自我审查的类路径容器，他们就不需要意识到了。

此外，根据我的经验，新手往往认为，由IDE中的大法师创建的项目是最好的创建项目的方式——如果IDE做了，那么它一定是正确的，不应该受到质疑。

因此，重要的是，您插件创建的项目在项目随着时间的推移而演变、更新其依赖项以及可能与团队一起开发时，实际上是有用的。（至少对于一个好的IDE来说，这是目标）

遗憾的是，自我中心的类路径提供者恰恰相反。

这不应该在团队中使用，因为所有jar文件都指向插件内的jar文件，因此它很可能依赖于用户运行的插件版本。如果团队不保持插件版本的同步，团队可能会运行不同的jar文件，导致可能的编译错误，最坏的情况是微妙的运行时差异。

自我中心的类路径容器常见的另一个问题是，它们只支持一个可能的运行时。这使得在您的工区内无法有使用不同版本jar的项目，例如，一个使用Java 5的Drools 4旧版本的项目和一个使用Java 6的Drools 5新版本的项目将需要多个Eclipse安装。

想象一下，如果Eclipse只支持与您运行Eclipse自身相同的Java版本的项目，那会怎么样？不太有用。

更糟糕的是，如果用户通过更新站点更新他的插件，他可能会无意中更改他项目的运行时依赖项，因为插件内的jar现在已更新。

其他示例

自我中心的类路径容器的另一个例子是Eclipse提供的Ant或JUnit类路径容器。这些也链接到Eclipse内部的类路径，导致上述描述的问题。虽然由于Ant和JUnit是非常稳定和成熟的框架，所以这并不是那么糟糕，但原则上这是错误的，您的项目不应该轻易使用这些类路径容器。

解决方案

好的，所以自我中心是不好的；插件应该做什么呢？

让我们看看每个人都应该知道的好类路径容器：由Eclipse Java开发工具（JDT）提供的JRE类路径容器。

截图显示了创建Java项目时类路径容器提供的内容。注意jar文件来自某些外部位置。这些位置在“已安装JRE”下的首选项中进行定义。

这些位置都有名字，允许团队只需同步使用哪些名字（实际上是id）作为其依赖项，它还允许在同一个Eclipse实例中使用多个运行时，并且它指向一个用户可控的良好定义的位置，即不依赖于您对eclipse插件的任何更新。

这个简单的概念，即为您的运行时定义显式的位置，有很大的不同，这是任何不错的插件如果希望提供框架特定的类路径容器应该做的。

这就是Drools团队最终所做的事情，结果是得到了一个非自我中心的类路径容器。

替代方案

当然，还有其他解决方案可以解决这个问题，即根本不使用插件提供的由插件提供的运行时，而是使用Ivy和Maven等工具进行完整的依赖项管理。

如果您想在Eclipse中使用完整的依赖项管理，请查看m2eclipse，它实际上提供了一个基于您的Maven依赖项计算jar的类路径容器。还有IvyIDE，它为Ivy做了同样的事情。

想了解更多吗

我和John Graham将在EclipseCon 2009上做一个题为"Max和John的卓越插件冒险 - 高光回放"的演讲，我们将展示并讨论上述反模式。

你有没有喜欢的Eclipse反模式？