【OSGi】OSGi与Maven、Eclipse PlugIn的区别
分类： 【OSGi】 2013-09-16 21:50 1840人阅读 评论(0) 收藏 举报
OSGimavenEclipse Plugin
目录(?)[+]
OSGi与Maven
Maven也具有模块化系统的特征；但是它只是一个编译时工具，而不是运行时框架。Maven并不是OSGi的竞争者，而是OSGi的一个补充。
通过在pom.xml中指定所依赖jar包的名称、版本号，Maven就能在编译时自动下载正确的jar文件，并部署到classpath中。
然而Maven并没有解决JAR文件的缺点：
同样使用全局的classpath；
同样不能做到包级别的信息隐藏；
而且pom.xml的格式与OSGi格式并不兼容。所以，如果用Maven编译OSGi系统，通常需要定义两遍metadata：
在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
Eclipse平台是基于Equinox的，而Equinox就是OSGi的实现之一。
而在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.