我应该使用Eclipse插件（或OSGi捆绑软件）作为普通的依赖项管理工具吗？

Question

再次发生了……我加入了一个新项目，该项目由几个相互依赖的简单Eclipse Java项目组成，所有项目都通过项目构建路径进行管理。 我觉得这有点混乱。 当涉及到运行配置时，您只需输入地狱即可。

过去，即使我从未打算将这些项目作为osgi-bundles运行，我仍然坚持创建插件项目，而不是普通的Java项目。 我只是发现依赖关系在插件项目中更易于管理。 其他人走同样的路吗？ 反对这种方法吗？

Answer 1

如果您阅读org.aspectj文档的重组，那么该项目正是这样做的：

• 所有依赖项都将在OSGi捆绑包清单文件中表示，该文件指定一个类路径（用于库jar）和“必需”捆绑包。
  出于构建和测试目的，必须包括部署环境中预期或希望的库（例如XML或JRocket ），但不应包括在发货产品中。 这些可能被指定为“可选”必需包或必需包

• 初始二进制程序集将通过通常的bundle程序集工作，bundle输出包括其所需的bundle片段中的二进制文件（但不包括可选的bundle中的二进制文件）

好处还包括OSGi的版本方面，它允许指定依赖项的最小和最大预期版本。

Answer 2

我同意，在Eclipse中，使用OSGi管理项目依赖关系比添加项目或库引用的传统方式要容易得多。

但是，如果在开发时推广OSGi-依赖性管理方式，则开发人员将需要学习OSGi，并且由于遇到类可见性问题而将付出一定的代价。

您是否正在使用Require-Bundle或Import-Package来管理依赖项？ 即使Require-Bundle不是OSGi的推荐选择，但从开发时间依赖性管理的角度来看，它可能更适合。

除非您使用Maven插件之类的东西，否则Eclipse将在Eclipse内部和外部进行完全不同的编译/运行方法的烦人分裂-维护2个并行编译/运行系统很麻烦。

Answer 3

我认为，即使您不在OSGi容器中运行，也要使用OSGi进行依赖项管理的方法非常合理，因为最终它将导致更多的模块化代码。 模块化代码更易于重构，更易于在多个开发人员之间分发。 您甚至不需要扩展任何OSGi类，因此无需创建任何其他依赖项。

另一方面，Ken Liu提出的使用外部依赖项管理的建议也具有其优势，因为Maven之类的东西将为您处理很多依赖项和管理。

结合两者，您将获得两全其美的体验。 可以使用Bnd和m2eclipse等其他库使OSGi与Maven一起使用。

Answer 4

听起来这是一种有趣的方法，但我个人认为最好使用Ant或Maven等外部构建工具来管理构建依赖关系，而不是将构建与IDE绑定。 如果您使用maven和m2eclipse插件，那么当其他项目也在您的工作空间中时，它将在装入Maven POM时自动设置Eclipse项目依赖项。

不幸的是，如果您的团队当前正在使用临时依赖管理，那么他们不太可能会想跳到Maven。 再说一遍，也许他们只需要一个领导者来带头努力。

Answer 5

我不会亲自使用插件项目，而会使用Ant，Maven等构建工具。

如果没有集成构建系统，则意味着该公司对软件开发的了解不多。

我不会全权负责引入构建系统，可能要花几个小时。 如果他们不想迁移，建议您尽快开始寻找另一份工作。

Answer 6

这里有两个独立的问题。

1. 如何设置多个项目，以及
2. 哪个构建系统允许我构建多个项目

两者不必关联。 因此，例如，您可以选择Maven来构建项目，但可以使用插件项目来简化编辑。 大多数事情击败了Eclipse构建系统。 一旦开始工作，它就相当稳定-但要使它从无到有地工作，将涉及（a）运气，和/或（b）黑魔法。

最终，问题归结为您觉得更容易管理； 两种类型的依赖关系，或仅一种依赖关系。 如果您只想要一个，则需要花费时间在m2eclipse之类的东西上（它从maven POM生成项目依赖项），或者使用pax-construct（它可以从maven POM生成清单）。 要么，要么与两个依赖项管理系统一起使用。