"OSGi方式"是开发包含离散,连贯功能的单独包.有时这些bundle包含实用程序类,有时它们依赖于实用程序类并设置自己的OSGi服务.
另一方面,用户不太可能接触到捆绑包.他们更关心应用程序,一个执行任务或解决问题的软件.通常,应用程序将使用多个包(例如,通过Import-Package导入)来执行其任务.
在OSGi世界中形式化这种关系的最佳方法是什么？一个示例要求就是向用户显示应用程序的当前版本号(而不是捆绑包)这么简单.如何发现这个版本号？
Eclipse有一个名为'features'的概念,但这不是OSGi标准.
Peter Kriens 撰写了关于OSGi应用程序的文章,他的文章很有意义.我对它的看法是应用程序可以映射到一个包; 只是捆绑以某种方式使用其他捆绑包.但是如果要使用Import-Package创建应用程序包,我不会从开发的角度看这是如何可行的.
一种方法可能是使用Require-Bundle并拥有自己的版本的"应用程序包",但在OSGi世界中,Require-Bundle不受欢迎.
但是,使用Import-Package导入具有所需版本的所有必需软件包会给开发人员带来很大的维护开销,以至于我认为它不可行.每次进行最小的更改,甚至是实现包,都必须更新包版本,然后在"应用程序包"中更新对包版本的依赖性.
框架是应用程序...... OSGi世界中最大的错误就是将OSGi视为一个多租户框架,它不是为此目的而设计的,并不适合.在框架内部,有很高的凝聚力,所有注册的服务都是您的服务.OSGi的架构模型允许您从通过服务连接的松散耦合组件编写应用程序.到目前为止,这是软件中最好的东西(尽管很遗憾会有很多缺失的组件会出现).
在bndtools中,我们竭尽全力帮助这个模型.bndtools bndrun文件基本上是一个可以部署的应用程序.bnd可以将此bndrun文件转换为带有Main-Class清单头的runnable Jar.(使用JPM,可以轻松部署在任何系统上.)
因此,工作流基本上是:设计您的服务(==架构),查找标准组件,开发缺少的组件,测试组件,测试集成,并将整个事物转变为可运行的JAR(或WAR).
显然,如果需要的话,你仍然可以在一个VM中运行多个框架,但是从不在同一个框架中运行不同的不相关的应用程序,这不是一个好主意,生活很难实现.