再一次发生了......我加入了一个新项目，由几个简单的Eclipse Java项目组成，具有相互依赖性，所有项目都通过Project构建路径进行管理。我发现这有点混乱。当涉及到运行配置时 - 你只需输入地狱。
在过去，我坚持创建插件项目，而不是简单的Java项目 - 即使我从未打算以osgi-bundle的形式运行这些项目。我发现插件项目中的依赖关系更容易管理。其他人走同样的道路吗？有什么反对这种方法吗？
答案 0 :(得分：2)
如果您阅读restructure of org.aspectj document，该项目就是这样做的：
所有依赖关系都将在OSGi包清单文件中表示，这些文件指定了类路径（用于库jar）和“必需”包。 部署环境中预期或希望的库（例如
XML或JRocket）必须包含在构建和测试目的中，但不包括在发货产品中。这些可能被指定为“可选”必需包或必需包初始二进制程序集将通过通常的bundle程序集，bundle输出包括它需要的bundle片段的二进制文件（但不包括可选的bundle）
优点还包括OSGi的版本方面，它允许指定依赖项的最小和最大预期版本。
答案 1 :(得分：2)
我同意在Eclipse中使用OSGi管理项目依赖关系比传统添加项目或库引用的方式更容易。
但是，如果您在开发时推广依赖于OSGi的依赖管理方式，开发人员将需要学习OSGi，并且在获得类可见性问题时会产生成本。
您是否使用Require-Bundle或Import-Package来管理依赖项？尽管Require-Bundle不是OSGi的推荐选择，但从开发时依赖性管理的角度来看，它可能更合适。
除非您使用的是Maven插件之类的东西，否则Eclipse会在Eclipse和外部编译/运行完全不同的方法，而且需要维护2个并行编译/运行系统。
答案 2 :(得分：1)
我认为，即使您不在OSGi容器内运行，使用OSGi进行依赖关系管理的方法也非常合理，因为最终它会导致更多的模块化代码。模块化代码更容易重构，更容易在多个开发人员之间分发。您甚至不需要扩展任何OSGi类，因此您不需要创建任何其他依赖项。
另一方面，Ken Liu建议使用外部依赖管理也有其优点，因为像Maven这样的东西会为你处理很多依赖和管理。
答案 3 :(得分：0)
这听起来像是一种有趣的方法，但我个人认为最好使用Ant或Maven等外部构建工具来管理构建依赖项，而不是将构建与IDE绑定。如果您使用maven和m2eclipse插件，它将在加载Maven POM时自动设置Eclipse项目依赖项，如果其他项目也在您的工作区中。
不幸的是，如果您的团队目前正在使用ad-hoc依赖关系管理，那么他们不太可能想要努力跳转到Maven。然后，也许他们只需要一位领导来带头努力。
答案 4 :(得分：0)
我不会亲自使用插件项目，我会使用Ant，Maven等构建工具。
如果没有集成构建系统，则意味着公司对软件开发了解不多。
我不会承担引入构建系统的所有责任，可能是额外的工作时间。如果他们不想迁移，我建议您尽快开始寻找其他工作。
答案 5 :(得分：0)
这里有两个不同的问题。
这两者无需相关。因此，例如，您可以选择Maven来构建项目，但使用插件项目来实现更轻松的编辑。大多数事情都击败了Eclipse构建系统。一旦它开始工作，它就相当稳定 - 但是从无到有，它涉及（a）运气，和/或（b）黑魔法。
最终，问题归结为你更容易管理;两种类型的依赖，或只是一个。如果你想要一个，那么你需要把时间投入m2eclipse（从maven POM生成项目依赖关系）或使用pax-construct（可以从maven POM生成清单）。要么，要么和两个依赖管理系统一起生活。