Java插件框架select

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

阅读了许多关于Java插件框架的文章后,似乎最常见的select是:

  • OSGI
  • “ 滚动你自己的 ”插件框架
  • Java插件框架 (JPF)
  • Java简单插件框架 (JSPF)

OSGI似乎比我们需要的更多。

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

所以我们下载到JPF和JSPF。 JPF似乎没有在积极的发展了。

JSPF看起来非常简单,实际上我们需要的只是。 但是我没有听说太多。 我只在StackOverflow上看过一篇文章 。 其他人有没有使用JSPF的经验? 或者有关这个deviseselect的其他意见?


更新 :这不一定是一个正确的答案..但是我们要去与Pavol的想法,因为我们只需要一个真正的,非常简单的解决scheme。 感谢EoH的好指导。

如果你打算只有一个(或者只有几个)不是很复杂的“扩展点”,那么可能是一个明确的SPI和一个configuration就足够了。 不需要使用插件框架。

我的意思是一些机制来find你的插件。 比如像META-INF/services/这样的东西,或者简单地把你的插件列在configuration文件中。

更多细节(根据要求):

SPI = 服务提供者接口 ,“API的实现者等价物”。 要了解更多信息,请尝试searchAPI和SPI之间的区别。 然而,在这种情况下,它只是一个界面被你的插件(即定义你的插件合同)实现的幻想术语。

由Ethan Nicholas撰写的一篇不错的简短文章“ 创build服务提供者接口 ”描述了如何以类似的方式创build自己的SPI,就像在Java平台本身的几个部分中完成的一样。

META-INF/services/可以被看作是一种更普遍的创buildSPI的方法。 有关更多信息,请参见JAR文件规范的相应部分。

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

我从JSPF开始的主要原因是因为我现在有同样的问题:我正在寻找一个简单的解决scheme,使我的论文项目1)可扩展和2)给它一个或多或less明确的代码结构。

我之所以还没有决定使用现有的框架,是因为其中大部分都是如此重量级的开始,我迷失在阅读文档,几乎忘记了我原来的任务。 所以,根据你的说法

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

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

然而,最终的决定还取决于你想达到什么目的,以及具体情况。

我听到了一些使用它来构build项目或在项目中加载插件的个人的积极成果。 另一方面,我也知道我们部门的一个人再次抛弃了,因为他觉得自己没有和他的编程风格相配合。

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

OSGi的项目和团队

  • 这是很大的,有很多人在工作
  • 这certificate了build立基础设施的开销
  • 需要提供的具体服务

JPF为项目和团队

  • 中等规模(?,老实说,我不知道他们的目标项目/团队规模)
  • 这需要更多的结构化设施来组织他们的代码,比如XMLconfiguration,详细的插件生命周期pipe理,可扩展的插件…

JSPF为项目和团队

  • 小规模,遵循敏捷的范式
  • 只是需要一些可以直接使用的东西,而不需要configuration或设置
  • 为了简单,愿意牺牲一些function

我希望你find最适合你的场景的插件框架。 而且,无论您尝试什么,我都会很乐意听到您的结果。

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