两个 Eclispse 项目 ->一个 Eclipse 插件
背景
我是 Vrapper 项目的开发人员。
Vrapper 包含 2 个主要部分
- Vim 仿真库 (vrapper.core)
- 充分利用它的 Eclipse 部分
我们希望 vrapper.core 不被 Eclipse 识别，因此可以重用 日食之外。目前，我们可以“vrap”各种 Eclipse 文本编辑器和我们用于单元测试的小模拟文本编辑器。
vrapper.core 实现了各种 Vim 命令、模式等。 这些都与平台通信——一个抽象出来的接口 底层的东西（文本编辑器、剪贴板、设置系统等）。
当为编辑器创建模式时，它会询问平台是否有额外的 适用于底层编辑器、当前编辑的文件类型等的命令。EclipsePlatform
使用 Eclipse 扩展点机制提供这些命令。
因此，让我们考虑以下项目（还有更多）：
- vrapper.core - Vrapper 的独立于 Eclipse 的代码
- vrapper.eclipse - 依赖于 的 Eclipse 插件>vrapper.core
- surround.core - 独立于 Eclipse 的代码，模拟 surround.vim （Vim 插件）
- surround.eclipse - vrapper.eclipse 的 Eclipse 片段 这使得它提供来自 surround.core 的命令。
我们可以通过两种方法来处理这些问题：
一个插件来统治所有
这些问题 从 Eclipse 的角度来看，它应该是这样的。 有一个插件包含来自 vrapper.eclipse 和 vrapper.core 的代码， 以及一个包含 surround.core 和 surround.eclipse 代码的片段。
插件很多
- 有3个插件
- 两个 OSG 化库 vrapper.core、surround.core
- vrapper.eclipse
- surround.eclipse 片段依赖在这种情况下，在 vrapper.core 上
问题
许多插件解决方案都存在一些我不明白的延迟类加载问题。 这是因为当创建来自 vrapper.core 的模式实例时，它们需要 要创建的 surround.core 中的类（通过 vrapper.eclipse -> surround.eclipse）。
如果您从 Eclipse 运行内容并从运行配置中选择所有插件，则此方法有效， 但如果部署了功能和功能，插件并正常运行 eclipse 抛出异常 因为无法找到 around.core 中的类。 这符合 Surround.core 的精神，要求来自 依赖插件会创建隐式循环依赖。
我所说的“隐式依赖”的意思是，没有核心类在编译时依赖于 Eclipse 特定的类。
模式（如 vim 正常模式）是核心类。它们包含命令。有一些特定于特定 Eclipse 编辑器的命令（例如运行此特定于 JDT 的重构）。这些命令实现了核心接口，但它们的代码（显然）存在于 Eclipse 特定的项目中。创建模式时，它会向底层平台询问一些额外的命令 - 这些额外的命令是在 eclipse 插件中实现的。这是当 Eclipse 中的延迟类加载使所有内容在运行时崩溃时 - 扩展点引用了额外命令的类，但它们尚未加载。繁荣，例外。
我尝试通过使用“一个插件来统治所有”的方法来解决这个问题。 对我来说，只有一个插件似乎是更好的解决方案，但我无法让它干净地工作。
对我来说唯一成功的是一个相当丑陋的黑客。
- 所有 .core 项目都有一个 Ant 任务，该任务使用其类创建 .jar 文件 并将其放入相应的 *.eclipse 项目
- *.eclipse 项目中包含该 jar 并将它们列入 MANIFEST 文件中。
这种丑陋的黑客方法的问题（除了它是丑陋的黑客）是 这种发展变得相当痛苦。 Eclipse 代码导航、代码覆盖率 Eclipse 中几乎没有其他东西停止工作。
总结
我们有eclipse独立库+eclipse特定的东西架构， 但我们确实需要将所有这些都存在于一个插件中（因为在两个方向上都存在一些依赖关系）。
如何将几个项目的代码集成到一个插件/片段中？
Background
I'm a developer of the Vrapper project.
Vrapper contains of 2 major parts
- Vim-emulation library (vrapper.core)
- Eclipse part that makes a good use of it
We want vrapper.core to be Eclipse-unaware, so it's reusable
outside of the Eclipse. Currently, we can "vrap" all sorts of Eclipse
text editors and our little mock text editor that we use for unit testing.
vrapper.core implements all sorts of Vim commands, modes, etc.
Those all communicate with Platform - an interface that abstracts out
underlying stuff (text editor, clipboards, settings system, etc.).
When mode is created for an editor it asks platform if there are extra
commands that are approperiate for underlying editor, currently edited file type, etc.
EclipsePlatform provides those commands using Eclipse extension points mechanism.
So, let's consider the following projects (there are more):
- vrapper.core - Eclipse-independent code for Vrapper
- vrapper.eclipse - Eclipse plug-in that depends on vrapper.core
- surround.core - Eclipse-independent code that emulates surround.vim (Vim plug-in)
- surround.eclipse - Eclipse fragment for vrapper.eclipse
that makes it provide commands form surround.core.
There are two ways we can deal with those:
One plug-in to rule them all
This is how it should look like from Eclipse's perspective.
There is one plug-in that contains code from vrapper.eclipse and vrapper.core,
and one fragment that contains code from surround.core and surround.eclipse.
Many plug-ins
- There are 3 plug-ins
- two OSGified libraries vrapper.core, surround.core
- vrapper.eclipse
- surround.eclipse fragment depends on vrapper.core in this case
Problems
Many plug-ins solution have some issues with lazy class loading that I don't understand.
It's beacause when instances of modes from vrapper.core are created they need
classes from surround.core to be created (via vrapper.eclipse -> surround.eclipse).
This works if you run stuff from Eclipse and select all plug-ins from run configuration,
but if one deploys features & plugins and run eclipse normally an exception is thrown
because classes from surround.core cannot be found.
It's something in the spirit of surround.core asking for extra commands from
dependent plug-ins creates implicit circular dependencies.
What I mean by implicit dependencies is that no core class depends on eclipse-specific classes in compile time.
Modes (like vim normal mode) are core classes. They contain commands. There are some commands specific for particular Eclipse editors (like run this JDT-specific refactoring). Those commands implement core interfaces, but their code (obviously) lives in eclipse-specific projects. When mode is created it asks underlying platform for some extra commands - those extra commands are implemented in eclipse plug-ins. This is when lazy class loading in eclipse make everything blow up in runtime - classes for extra commands are referenced by extension points, but they are not yet loaded. Boom, exception.
I tried to work this around by using "one plug-in to rule them all" approach.
Having just one plug-in seems to be much better solution to me, but I couldn't make it work cleanly.
Only thing that succeeded for me was quite an ugly hack.
- All .core projects had an Ant task that created .jar file with their classes
and dropped it into corresponding *.eclipse project - *.eclipse projects included that jars and had them enlisted in MANIFEST files.
The problem with this ugly hack approach (besides of it being ugly hack) is
that development becomes quite painful. Eclipse code navigation, code coverage
and few other things in Eclipse stops working.
Summary
We have eclipse independent library + eclipse specific stuff architecture,
but we really need all of this to live in one plug-in (because there are some dependencies in both directions).
How do I make code from few projects live into one plug-in/fragment?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事实证明，将 Eclipse-BuddyPolicy: dependent 添加到 MANIFEST.MF 文件中，重新导出一些依赖项并将一个片段转换为插件（因此 BuddyPolicy 可以跟踪插件依赖项）是正确的解决方案。
问题解决了:-)
It turned out that adding Eclipse-BuddyPolicy: dependent to MANIFEST.MF files, reexporting some dependencies and turning one fragment into plugin (so there is plug-in dependency for BuddyPolicy to track) was the right solution.
Problem solved :-)
从阅读本文来看，实际问题似乎在于两个方向上都存在依赖关系。难道您不能重构您的项目以仅使 Eclipse 特定的项目依赖于核心项目，而不是相反吗？
From reading this it sounds as if the actual problem is the fact that there are dependencies in both directions. Can't you refactor your projects to make only the Eclipse-spcific proejcts depend on the core projects, and not the other way around?