Java插件框架选择

时间:2009-10-23 14:43:20

标签: java osgi plugin-architecture

我们正在尝试确定如何为我们正在实施的服务实现一个简单的插件框架,该服务允许不同类型的计算器“插入”。

在阅读了有关Java插件框架的number帖子后,似乎最常见的选项是:

OSGI似乎超出了我们的需要。

“滚动你自己”是好的,但重用一个公共库会很好。

所以我们归结为JPF和JSPF。 JPF似乎不再处于积极发展阶段。

JSPF似乎非常简单,而且我们真的需要它们。但是我没有听到太多关于它的消息。我在StackOverflow上只看到一个post。有没有其他人有JSPF的经验?或者对这个设计选择的任何其他评论?


更新:对此没有一定的正确答案..但是我们将采用Pavol的想法,因为我们只需要一个非常非常简单的解决方案。感谢EoH的好导游。

3 个答案:

答案 0 :(得分:43)

(免责声明:我是JSPF的作者,所以最好把我的评论带上一粒盐; - )

我开始使用JSPF的主要原因是因为我遇到了与现在相同的问题:我正在寻找一个简单的解决方案,使我的论文 - 项目1)可扩展,2)给它一个或多或少的清晰代码结构体。

我之所以没有决定使用现有框架的原因是因为他们中的大多数都是如此重量级的开始,我在阅读文档时迷失了,并且几乎忘记了我原来的任务。所以,根据你的陈述

  

我们正试图确定如何   实现一个简单的插件框架   对于我们正在实施的服务   允许不同类型的计算器   被“插上”。

我认为你可以给JSPF一个镜头,看看你在一两个小时内到达了多远。

然而,最终决定还取决于您想要实现的目标,以及具体情况。

我听过许多人使用它来构建项目或在项目中加载插件的积极结果。另一方面,我也知道我们部门的一个人再次丢弃它,因为他觉得它与他的编程风格并不完美。

所以,为了简单回答你的问题(肯定是有偏见的),我会用

项目和团队的

OSGi

  • 哪个很大,有很多人在上面工作
  • 证明设置基础设施的开销
  • 需要提供的特定服务
项目和团队的

JPF

  • 中等规模(?老实说,我不确定他们所针对的项目/团队规模)
  • 需要更多结构化的工具来组织他们的代码,比如XML配置,详细的插件生命周期管理,可扩展的插件......
项目和团队的

JSPF

  • 小尺寸,遵循敏捷范例
  • 只需要开箱即用的东西,无需配置或设置
  • 愿意为了简单而牺牲一些功能

我希望您找到最适合您的方案的插件框架。而且,无论您尝试什么,我都会很高兴听到您的结果。

答案 1 :(得分:29)

如果您计划只有一个(或只有几个)不是非常复杂的“扩展点”,那么可能只是一个明确定义的SPI,而且一段配置可能就足够了。无需使用插件框架。

通过一段配置我的意思是找到你的插件的一些机制。例如META-INF/services/之类的内容,或者只是在配置文件中列出插件。

更多细节(根据要求):

SPI = Service Provider Interface,“API的实施者端等价物”。要了解更多信息,请尝试搜索API和SPI之间的差异。但是在这种情况下,它只是一个由插件实现的接口的一个奇特的术语(即定义插件的合同)。

Ethan Nicholas撰写的一篇很好的短文“Creating a Service Provider Interface”描述了如何以类似于Java平台本身的部分方式创建自己的SPI。

META-INF/services/可被视为创建SPI的更通用方法。更多信息可以在JAR File Specification的相应部分找到。

答案 2 :(得分:2)

如果您需要一个非常简单的解决方案,请尝试jin-plugin。它是Java和PHP的简约插件框架。