背景
我是Vrapper项目的开发人员。
Vrapper 包含 2 个主要部分
- Vim 仿真库 (vrapper.core)
- 充分利用它的 Eclipse 部分
我们希望 vrapper.core 不支持 Eclipse，因此它可以在 Eclipse 之外重用。目前，我们可以“vrap”各种 Eclipse 文本编辑器和我们用于单元测试的小型模拟文本编辑器。
vrapper.core 实现了各种 Vim 命令、模式等。它们都与 Platform 通信 - 一个抽象出底层内容（文本编辑器、剪贴板、设置系统等）的接口。
当为编辑器创建模式时，它会询问平台是否有适合底层编辑器、当前编辑的文件类型等的额外命令。
EclipsePlatform 使用 Eclipse 扩展点机制提供这些命令。
因此，让我们考虑以下项目（还有更多）：
- vrapper.core - Vrapper 的 Eclipse 独立代码
- vrapper.eclipse - 依赖于vrapper.core的 Eclipse 插件
- 环绕.core - 模拟环绕.vim （Vim 插件）的独立于 Eclipse 的代码
- 环绕.eclipse - vrapper.eclipse的Eclipse 片段 ，使其提供来自环绕.核心的命令。
我们有两种方法可以处理这些问题：
一个插件来统治他们
从 Eclipse 的角度来看，这就是它的样子。有一个插件包含来自vrapper.eclipse和vrapper.core的代码，还有一个片段包含来自环绕.core和环绕.eclipse 的代码。
很多插件
- 有3个插件
- 两个 OSGified 库vrapper.core，surround.core
- vrapper.eclipse
- 在这种情况下，环绕.eclipse片段依赖于vrapper.core
问题
许多插件解决方案都有一些我不理解的延迟类加载问题。这是因为当创建来自vrapper.core的模式实例时，它们需要创建来自 round.core 的类（通过vrapper.eclipse -> round.eclipse）。
如果您从 Eclipse 运行东西并从运行配置中选择所有插件，则此方法有效，但如果部署功能和插件并正常运行 eclipse，则会引发异常，因为无法找到来自 round.core 的类。这是环绕核心的精神，要求来自依赖插件的额外命令创建隐式循环依赖。
我所说的隐式依赖是指在编译时没有核心类依赖于 eclipse 特定的类。
模式（如 vim 普通模式）是核心类。它们包含命令。有一些特定于特定 Eclipse 编辑器的命令（比如运行这个 JDT 特定的重构）。这些命令实现了核心接口，但它们的代码（显然）存在于特定于 eclipse 的项目中。创建模式时，它会向底层平台询问一些额外的命令——这些额外的命令在 eclipse 插件中实现。这是当 Eclipse 中的延迟类加载使一切在运行时崩溃的时候——扩展点引用了额外命令的类，但它们还没有加载。繁荣，例外。
我试图通过使用“一个插件来统治它们”的方法来解决这个问题。对我来说，只有一个插件似乎是更好的解决方案，但我无法让它干净利落地工作。
对我来说唯一成功的是一个非常丑陋的黑客。
- 所有.core项目都有一个 Ant 任务，该任务使用它们的类创建 .jar 文件并将其放入相应的*.eclipse项目中
- *.eclipse项目包括这些罐子，并将它们列入清单文件。
这种丑陋的 hack 方法的问题（除了它是丑陋的 hack）是开发变得非常痛苦。Eclipse 代码导航、代码覆盖率和 Eclipse 中的其他一些东西停止工作。
概括
我们有eclipse 独立库 + eclipse 特定的东西架构，但我们真的需要所有这些都存在于一个插件中（因为在两个方向上都有一些依赖项）。
如何将少数项目的代码集成到一个插件/片段中？