【OSGi】OSGi与Maven、Eclipse PlugIn的区别





  • 同样使用全局的classpath;
  • 同样不能做到包级别的信息隐藏;


  • 在pom.xml中定义Maven的metadata
  • 在MANIFEST.MF中定义OSGi的metadata


Maven and Ivy are both popular tools that have some characteristics of a module system, but they are build-time tools rather than runtime frameworks. Thus they do not compete directly with OSGi, in fact they are complementary and many developers are using Maven or Ivy to build OSGi-based systems.

Maven is a complete, standalone build tool, whereas Ivy is a component that can be integrated into an ANT-based build. Both tools attempt to make JARs more manageable by adding modular features to them. Principally this means dependencies: both allow us to specify the versioned dependencies of a JAR using metadata in XML files. They use this information to download the correct set of JARs and construct a compile-time classpath.

However, as they do not have any runtime features neither Maven nor Ivy can solve the runtime problems with JARs, such as the flat global classpath, the lack of information hiding, and so on. Also the metadata formats used by these
tools is unfortunately not compatible with the format used by OSGi, so if we use Maven or Ivy to build an OSGi-based system we typically have to specify the metadata twice: once for OSGi and once for the build tool. However, some efforts are currently being made to better integrate Maven with OSGi.

OSGi与Eclipse PlugIn


而在Eclipse3.0之前,却使用的是另一套模块系统;Eclipse PlugIn是指包含plugin.xml的文件夹;plugin.xml中定义的metadata和OSGi的MANIFEST.MF非常类似:包含plugin的name、vendor、version、导出包、required plugin。

关键的区别在于:Eclipse PlugIn定义的依赖并不是包级别,而是整个plugin。

Eclipse Plugin的最大缺陷是,不能动弹地安装、更新、卸载。


As already noted, the Eclipse IDE and platform are based on an implementation of OSGi. However this was not always the case: prior to version 3.0, Eclipse used its own custom module system.

In Eclipse terminology, a module is a “plug-in”. In fact, Eclipse developers often still use the term plug-in as an alternative name for an OSGi bundle. In the old Eclipse system, a plug-in was a directory containing a file at the top level named plugin.xml. This file contained metadata that was broadly similar to the metadata in an OSGi manifest: the name of the plug-in, vendor, version, exported packages and required plug-ins.

Notice a key difference here. In the Eclipse plug-in system, dependencies were not declared at the level of Java packages but of whole plug-ins. We would declare a dependency on a plug-in based on its ID, and this would give us access to all of the exported packages in that plug-in. OSGi actually supports whole-bundle dependencies also, but the use of this capability is frowned upon for reasons we will examine in Chapter 3.

The biggest deficiency of the Eclipse plug-in system was its inability to install, update or uninstall plug-ins dynamically: whenever the plug-in graph changed, a full restart was required. In early 2004 the core Eclipse developers began a project, code-named Equinox, to support dynamic plug-ins. They intended to do this either by enhancing the existing system or selecting an existing module system and adapting it to Eclipse. In the end, OSGi was selected and Equinox became a leading implementation of it.

©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
钱包余额 0