将OSGi捆绑软件分组以创建一致的“应用程序"的最佳方法是什么 [英] What is the best way of grouping OSGi bundles to make a coherent 'application'

问题描述

"OSGi方式"是开发包含不连续的，连贯的功能的单独捆绑包.有时，这些捆绑软件包含实用程序类，有时它们依赖于实用程序类并设置自己的OSGi服务.

The "OSGi way" is to develop separate bundles containing discrete, coherent pieces of functionality. Sometimes these bundles contain utility classes, sometimes they depend on utility classes and set up their own OSGi Services.

另一方面，用户不太可能接触捆绑软件.他们更关心应用，这是一种执行任务或解决问题的软件.通常，应用程序将使用多个捆绑包(例如，通过Import-Package导入)来执行其任务.

Users, on the other hand, are unlikely to be exposed to bundles. They care more about the application, a piece of software that performs a task or solves their problem. Normally an application will use multiple bundles (say, imported via Import-Package) to perform its tasks.

在OSGi世界中正式化这种关系的最佳方法是什么?一个示例要求将是与显示应用程序的当前版本号 一样简单(不是捆绑销售给用户).如何找到此版本号?

What is the best way to formalise this relationship in the OSGi world? One example requirement would be something as simple as showing the current version number of the application (not the bundle(s)) to to the user. How would this version number be discovered?

Eclipse有一个称为功能"的概念，但这不是OSGi标准.

Eclipse has a concept called 'features' but this is not OSGi standard.

Peter Kriens已写了有关OSGi应用程序的文章及其文章说得通.我的不足之处是，应用程序可以映射到捆绑软件.只是捆绑软件以某种方式使用了其他捆绑软件.但是，如果要使用Import-Package创建应用程序捆绑包，从开发的角度来看，我看不到这是可行的.

Peter Kriens has written about OSGi applications and his article makes sense. My take away from it was that an application can map to a bundle; it's just that the bundle uses other bundles in some way. But if one is to create an application bundle using Import-Package, I don't see how that can be feasible from a development point of view.

一种方法可能是拥有一个使用Require-Bundle并具有其自己版本的应用程序捆绑包"，但是Require-Bundle在OSGi世界中不受欢迎.

One way may be to have an 'application bundle' that uses Require-Bundle and has its own version, but Require-Bundle is frowned up in the OSGi world.

使用Import-Package导入具有所需版本的所有必需软件包，但是在我认为不可行的范围内，这给开发人员增加了相当大的维护开销.每次进行最小的更改，即使是对实现程序包，都必须更新程序包版本，然后在应用程序捆绑包"中更新对程序包版本的依赖性.

Using Import-Package to import all the required packages with the required versions, however, adds a significant maintenance overhead to the developer to the extent that I don't think it's feasible. Each time the smallest change is made, even to an implementation package, the package version must be updated, and then the dependency on the package version updated in the 'application bundle'.

推荐答案

框架是应用程序……OSGi世界中最大的错误是将OSGi视为多租户框架，它并不是为此而设计的目的，这不是一个很好的选择.在框架内部，凝聚力很高，所有注册的服务都是您的服务. OSGi的体系结构模型允许您从通过服务连接的松散耦合组件中编写应用程序.到目前为止，这是imho在软件中获得的最好的回报(尽管不幸的是，将会有很多缺少的组件出现).

The framework is the application ... The biggest mistake imho in the OSGi world is to see OSGi as a multi-tenant framework, it was not designed for that purpose and it is not a good fit. Inside a framework, there is high cohesion, all services registered are your services. The architectural model of OSGi allows you to write applications from loosely coupled components wired through services. Which is imho by far the best it gets in software (though there are lots of missing components unfortunately, will come).

在bndtools中，我们竭尽全力为该模型提供帮助. bndtools bndrun文件基本上是可以部署的应用程序. bnd可以将此bndrun文件转换为带有Main-Class清单头的可运行Jar. (借助JPM，将可以轻松地在任何系统上进行部署.)

In bndtools we go out of our way to help with this model. A bndtools bndrun file is basically an application that you can deploy. bnd can turn this bndrun file into runnable Jar with a Main-Class manifest header. (And with JPM it will be easy to deploy on any system.)

因此，工作流程基本上是:设计服务(=体系结构)，查找标准组件，开发缺少的组件，测试组件，测试集成，并将整个过程变成可运行的JAR(或WAR).

So the workflow is basically: design your services (== architecture), find standard components, develop missing components, test the components, test the integration, and turn the whole thing into a runnable JAR (or WAR).

很显然，如果需要，您仍然可以在单个VM内运行多个框架，但是绝不能在同一框架内运行不同的无关应用程序，这不是一个好主意，生活已经足够艰难了.

Obviously you can still run multiple frameworks inside a single VM if so desired, but never run different unrelated applications in the same framework, not a good idea, life is hard enough as it is.

这篇关于将OSGi捆绑软件分组以创建一致的“应用程序"的最佳方法是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！