如何在Eclipse PDE中表达项目间依赖项
我正在寻找处理混合项目类型之间的项目间依赖关系的最佳实践，其中一些项目是eclipse插件/ OSGI包项目（一个RCP应用程序），而其他项目只是普通的旧Java项目（Web服务模块）。 很少有eclipse插件依赖于Java项目。
我的问题是，至少就我看来，没有办法在Eclipse PDE环境中干净地表达这种依赖。 我可以让插件项目依赖于其他插件项目（通过Import-Package或Require-Bundle清单头），而不是普通的java项目。
我似乎能够让项目从工作空间中的另一个项目声明对jar的依赖，但这些jar文件既不会被导出也不会被启动配置（虽然，java代码编辑看到库很好）。
“Java项目”用于构建服务以部署在J2EE容器（目前是JBoss 4.2.2）上，并在某些情况下生成多个jar – 一个用于部署到JBoss耳朵，另一个用于客户端代码（一个用于客户端代码） RCP应用程序）。
我们现在解决这个问题的方式是我们还有2个外部工具启动器配置 – 一个用于构建所有jar，另一个用于将这些jar复制到插件项目中。 这样做（有点），但是“整个构建”和“复制jar子”目标会产生相当大的构建步骤，绕过整个eclipse增量构建function并通过复制jar而不是仅仅引用项目我将依赖关系信息解耦并请求相当大的工作空间刷新，这就像糖果一样耗尽了开发时间。
我想要的是一个更加“自然”的工作空间设置，它可以管理项目之间的依赖关系并仅在需要时请求增量重建，能够使用RCP应用程序插件中的服务库中的客户端代码并且能够启动RCP应用程序，其中包含所需的所有必需类。
我也可以吃蛋糕了吗？）
注意
需要说明的是，目前依赖管理和模块管理与Eclipse PDE配置有关。
我很清楚像[Maven]，[Ivy]和[Buckminster]这样的产品，他们解决了一个完全不同的问题（一旦我解决了工作区配置问题，这些产品实际上可以派上用场实现工作空间并构建产品）
我从来没有这样做过，所以这是一种理论方法。 但我会尝试像ivy或maven2这样的依赖管理系统。
由于maven2做得更多，然后只是依赖管理，我建议在这种情况下使用常春藤。
Eclipse项目依赖于项目属性（依赖项目？）中的复选框，这就是Eclipse决定构建哪个项目的方式。 您可以自己设置，但通常在更改Java构建路径时设置。 它将数据存储在.project文件IIRC中，因此一旦您浏览了GUI并看到了哪些更改，您就可以更灵活地应用其他文件。
但是，听起来你想要混合搭配Jars和Bundles。 简单的方法是将所有项目视为Java项目。 在PDE项目中，您实际上可以进入并调整Java构建路径; 它会抱怨并说这不是正确的方法，但它会让你拥有一个PDE项目依赖于Java项目而没有那么蓬松的JARing。 话虽如此，如果这种方法存在运行时问题，我也不会感到惊讶 – PDE运行时可能不会这样看。
另一种方法是让你的JAR自己成为PDE / OSGi包。 毕竟，一个OSGi包只不过是一个JAR，它在Manifest中有一些额外的function，它可以让你使用自动依赖管理轻松地开发和组装你的项目。 这可能是最容易实现的，即使你真的不需要清单出现在你的捆绑包中。 但这样做意味着您的PDE应用程序可以采用更模块化的方法，而不是根据需要在每个插件中嵌入库。
因此，PDE可以生成OSGi包，这只是JAR + Manifest的另一个名称。 您可以在其他环境中以完全相同的方式使用JAR（例如，对于您的EAR或其他客户端使用），您可以利用应用程序中的OSGi层。 考虑到你所谈论的混合束的类型，没有理由不这样做。
我们的解决方案使用Ant构建器将普通Java项目的“classes”目录直接复制到插件项目的顶层目录中。 我们跳过JAR构建步骤以节省时间，并且它运行良好。 如果插件项目依赖于已经构建的外部JAR，我们也会复制它们。
这里是如何在Eclipse 3.5中设置它（抱歉奇怪的格式，但这是我能找到保留缩进的唯一方法）：
Create empty "classes" dir in plugin project Select plugin project, hit F5 to refresh resources Create new Ant build file in plugin project to copy dependencies (ours is shown below) Right-click plugin project, select Properties Select Builders Click "New..." (brings up Edit Configuration dialog) Select Ant Builder and click "OK" Name your builder (ours is called "PluginProject externals") Browse workspace for Buildfile (ours is ${workspace_loc:/PluginProject/copyDependencies.xml}) click Refresh tab check "Refresh resources upon completion", click "Specific resources" click "Specify Resources...", check box for the classes dir, click "Finish" Click "OK" (closes Edit Configuration dialog) Click "Up" to move "PluginProject externals" to top of builder list Click "OK" (closes Properties dialog) Open your plugin project's MANIFEST.MF Click "Runtime" tab Click "Add..." under "Classpath", select your the "classes" dir and JARs and click "OK"
在插件项目中手动创建空的“classes”目录是为了让您可以告诉新构建器刷新该资源（在新构建器运行之前尚不存在）。 这是我们的copyDependencies.xml文件中的内容：
Copies external dependency class andd JAR files into this plugin's directory.
这个方法唯一的缺点似乎是Eclipse在调用外部构建器时不是100％完美，所以偶尔你必须在Eclipse中执行“Project> Clean …”来强制它。
你有我的同情心。 我也与这个问题作斗争，而Eclipse开发的Wall-of-Silence开发了一个如此简单明了的问题：如何从插件声明一个依赖项到普通的Java项目（这样它在运行时工作）？
我不认为他们支持它。 我遇到问题的唯一方法是在我的插件项目中创建文件夹，这些文件夹实际上是指向java项目的bin /文件夹的链接，然后将这些文件夹包含在插件中。 这至少有效，但由于需要绝对的文件系统路径，它很脆弱。
也许你可以在Eclipse上使用“项目属性” – >“部署程序集”，并将其他项目添加到主项目中。 其他项目看起来像“jar子”，自动添加到您的部署文件（战争，耳朵或其他）。 也许这可行。 至少它对我有用。 祝好运 ！！
Ariesandes。
“构建路径”属性中有一个“链接源”选项，允许您为项目定义其他源文件夹。 您可以选择另一个工作区项目的“src”文件夹，并将其重命名为“src2”或任何您想要的。 这样，类被编译并部署到插件项目输出文件夹中，并且可以在运行时加载。
有了一组复杂的构建依赖关系，我发现Maven2和Hudson（用于CI）是一个非常好的组合。 设置基础架构需要一段时间才能完成配置，但在此之后，它才起作用。
当然，您依赖于Maven2（或Hudson）对构建机制的支持。 我不确定Eclipse Headless构建的支持程度如何。 但是，如果您使用Eclipse无头的唯一原因是允许依赖关系在一个地方表达，请自己帮忙并切换。
我遇到了完全相同的问题。 我们有一组可以由Maven构建的多个普通java项目，并且（当前）应该共享相同的类路径以正常工作。 这些项目可用于在非OSGi环境中启动服务器。 然后我们还有一个eclipse RCP客户端，它将这些项目作为一个捆绑包使用。 我完全能够使用Apache Felix Maven Bundle插件使用Maven构建这个大包，一切正常。 但每当我在正常项目中更改一个类时，我必须重建整个包。 增量构建和资源链接不起作用。
我尝试了将这些项目中的二进制文件/源目录链接到一个大包的Manifest类路径中的“解决方案”，它似乎可以工作，但这将是一个真正的维护噩梦，因为我甚至必须链接一些单独的文件。
具有讽刺意味的是，由于OSGi在客户端中的使用，我实际上正在考虑将我们漂亮的模块化结构与Maven模块合并到一个插件项目的子包中。 这是一个比开发速度极慢的更好的选择。
我将首先研究的另一个更好的替代方案（根据OSGi人员）是将我的所有Maven模块都变成OSGi包。 但这可能是一个真正的PITA，因为我依赖于类路径扫描并组合来自多个包（有时是同一个名称）的多个配置文件来形成一个配置。
（具体来说，我们使用Spring框架，并将多个persistence.xml文件合并到一个持久化上下文中。我们还合并了来自不同模块的几个spring XML上下文文件（都提供了不同的ASPECT），这些文件应该共同形成一个Spring上下文，供Spring使用-DM）。