OSGi.NET的什么是OSGi.NET
OSGi全称为Open Service Gateway Initiative，它一方面指由IBM、Oracle、BEA、SAP等国际IT巨头组成的OSGi联盟组织；另一方面指该组织制定的一个基于Java语言的服务规范——OSGi服务平台。基于OSGi.NET的插件框架提供了模块化与插件化、面向服务架构和模块扩展三大功能，适用于控制台、WinForm、Windows服务、WPF、ASP.NET和移动平台等任意.NET应用环境。
几种OSGI bundle的打包方法及注意事项
前言：我相信做基于OSGI框架开发的朋友，对于OSGI的基本单元Bundle应该并不陌生，平时的开发中，做得最多事情就是bundle的开发和打包了，打包其实属于蛮重要的一个过程，为什么说他重要呢，其实打包的过程就是一个理清bundle依赖关系的过程，在对OSGI的学习和使用过程中，个人觉得最令人头痛的就是bundle之间的依赖关系，而且我到现在为止还没有找到一种比较好的工具能够很好的管理OSGI环境中的各个bundle的依赖关系。不过现在公司也有开始考虑做一些类似phpadmin，mysqladmin这样的基于web的管理工具来对bundle进行统一管理，在这之前，如何解决依赖关系，如何将bundle正确的打包出来并进行部署成了OSGI开发中的一个主要问题，而这篇文章中，我主要介绍目前我自己用过得几种打包方式，总结下经验，如果大家有更好的方法或者有不清楚的地方也可以提出来一起讨论~ 第一种方法就是直接通过eclipse提供的export功能，来直接导出一个一个插件工程，这个过程，相信大家已经用的很熟悉了，直接eclipse给你的提示一步步来就可以了。 这里我只想稍微提几个注意的问题，首先是在打包的时候注意把必要的资源文件给勾选上，像我有时就忘记勾选上一些OSGI service的配置文件，而导致service不能发布或者获取。其次，检查好你的项目自描述文件MANIFAST.MF里面的OSGI相关的配置信息是否都已经写正确，该export和该import的包是否写对，个人觉得OSGI最让人头疼的就是解决bundle之间的依赖关系，有时候OSGI环境一大，依赖关系变得复杂，导出包，引用包常常会容易混淆，所以对OSGI环境中的组件的依赖进行统一管理和限定，可以使bundle的依赖更加清晰，环境也易于管理，降低OSGI开发复杂度。最后，有时候在导出包的时候会碰到一些问题，比如bundle之间循环调用，多半还是由于Bundle之间的依赖发生了冲突的关系，检查一下是否多个bundle是否导出了相同包，bundle的引入包是否正确等等。 第二种方法则是利用apache为maven2.0提供的一个专门来打OSGI包的felix（http://felix.apache.org/site/maven-osgi-plugin.html）插件来利用maven进行OSGI bundle的打包工作，felix这个插件在maven中的使用还是比较容易的。官方网站（http://cwiki.apache.org/FELIX/osgi-plugin-for-maven-2.html）上给出了一个比较详尽的使用说明，这里我大致说明一下，只需要在项目的pom文件中配置一个plugin就ok了，最简单的配置如下： xml 代码 org.apache.felix.pluginsgroupId> maven-osgi-pluginartifactId> trueextensions> 0.3.0version> resources/manifest.mfmanifestFile> configuration> plugin> plugins> 当然，这种配置就是告诉maven在对你的项目进行打包的时候直接使用resources/manifest.mf文件进行打包了，除此之外，如果你并不想一开始就指定一个MANIFAST.MF文件，而是将这个工作在打包过程交给felix去完成的话，那么你可以为MANIFAST.MF文件配置一些必要的属性，然后felix会根据这个属性来生成一个MANIFAST.MF一起打包到项目中，如： xml 代码 org.apache.felix.pluginsgroupId> maven-osgi-pluginartifactId> trueextensions> 0.3.0version> My OSGi ApplicationbundleName> An example bundle applicationbundleDescription> org.safehaus.bundle.ActivatorbundleActivator> org.osgi.service.logimportPackage> SafehausbundleVendor> osgiManifest> configuration> plugin> plugins> 显然，从标签开始，你就是在手动的写一个MANIFAST.MF文件的相关OSGI配置信息了，此外你还可以加上一些打包配置来将指定的资源文件进行打包，如： 在标签以内加入如下的设定 -target/classes/META-INF/details.bnd target/classes 第一种是告诉maven将一个指定文件打包 第二种是设定编译后类文件的存放位置 这里提供一个实际运用的简要配置模板实例，大家可以稍作修改就可以直接使用了： xml 代码 org.apache.felixgroupId> maven-bundle-pluginartifactId> trueextensions> ${project.version} Bundle-Version> $(replace;${project.artifactId};-;_);singleton:=true Bundle-SymbolicName> target/classes_classpath> com.yourcompany.artifactId.*;version="${project.version}" Export-Package> org.springframework.test;resolution:=optional,* Import-Package> *DynamicImport-Package> -target/classes/META-INF/details.bnd _include> Include-Resource> instructions> configuration> plugin> 以上仅是我在实际项目中打包时候的设置过得一个样例，仅供大家参考，大家可以根据实际项目信息来自行设置自己的项目描述。具体的其他OSGI相关配置所应对应设定什么样的标签的内容，请参考apache官网（http://cwiki.apache.org/FELIX/osgi-plugin-for-maven-2.html）提供的参考。 配置完毕后，在当前项目目录下，运行maven的package命令，就能得到一个由你自己自配置的一个OSGI bundle了。 第三种方式： 利用OPS4J组织提供的一个叫Pax的工具来进行OSGI bunder的构建. 这里需要说的就是，我什么要用PAX来构建一个OSGI工程呢，eclipse不是已经有很好的OSGI开发支持了么，这里要说的就是，PAX构建的OSGI工程并不是单单某个OSGI bundle的开发，而是，PAX会主动的为你创建一个基本的OSGI环境，这个环境包括一些OSGI的基础包，你可以通过PAX的命令来启动这个OSGI环境，同时PAX也会将其管理的一些Bundle进行打包实时发布到这个环境中，这样不但可以按需的打包bundle，还可以迅速的构建一个OSGI环境来进行调试了。这里我简要的说一下PAX的使用方法，PAX是一个专门用来构建和管理OSGI 环境的一个工具，从官网的介绍我们可以看到，他主要提供pax-create-project pax-add-repository pax-create-bundle pax-import-bundle pax-embed-jar pax-wrap-jar pax-move-bundle pax-remove-bundle 等几大脚本命令来，完成一些儿OSGI环境的构建工作。这里我只简要介绍一下我平时几条最常用的命令，通过这些命令的介绍来大概的给大家讲解一下pax的使用方式。首先从官方down到pax的最新包 Down好后，进行解压，解压完毕后，为了在命令行中使用，你需要将其中的bin目录设置到环境变量PATH中，设置完毕后你就可以到你希望创建项目的目录，利用PAX提供的第一条命令pax-create-project来创建一个OSGI工程。创建好这个工程后，我们就可以利用maven的命令来启动这个OSGI的环境工程，pax会为帮我们构建一个基础OSGI环境，以及将test工程中的bundle工程打成bundle部署到这个环境中去，当然我们现在还为在这个工程中创建任何bundle工程，所以，我们启动的只是一个最小的OSGI环境。 接下来我们在这个PAX的工程中来创建我们bundle工程，pax提供四种命令来创建bundle的打包工程pax-create-bundle pax-import-bundle pax-embed-jar pax-wrap-jar pax-create-bundle是完全用pax创建一个符合OSGI规范bundle项目，最后在执行mvn clean install pax:provision命令时，pax会把这个工程打成一个bundle然后部署到它的OSGI环境中去。 pax-import-bundle 则是直接导入一个符合OSGI规范的bundle，这样在启动OSGI环境的时候pax会去指定group(-g)，指定的artifactId(-a)和指定的version(-v)的repository下去搜索指定的OSGI bundle并将其导入到环境中。 pax-wrap-jar 通过该命令则可以利用pax将一个jar包打包成一个符合OSGI规范的bundle，pax能够对这个jar包进行分析，找出其中的依赖关系，并生成相关的MANIFAST.MF文件。再吧这个bundle部署到之前的OSGI环境中去。 在项目中我最常用的就是以上三条，其余的命令，以及这些命令的具体使用方法大家可以参考官方网站给出的示例。 接下来，我就利用pax-create-bundle命令来创建一个bundle工程，来给大家演示一下。 先选择到一个需要创建工程的目录下 看看一个test工程生成了，可以看到pax实际上给我们生成了一些初始的pom，大家可以打开看看 接下来我们马上来跑下这个工程。看看pax会给我们带来什么效果 先进入到text目录，大家可以打开pax生成的pom.xml看看，实际上pax是把自己作为了一个maven的插件来供maven调用，这里我们用maven来运行这个工程，命令是mvn clean install pax:provision 可以看到pax为我们启动了一个OSGI运行环境，我们用ss命令来查看但前环境中的bundle信息 呵呵，果然是一个最小的OSGI环境。 接下来我输入命令来创建一个bundle工程： pax-create-bundle -g com.zhoufu.demo -a create_bundle_demo -v 1.0,接下来看看pax会为我们产生什么可以看到在test环境工程下，pax为我们创建了一个符合OSGI规范的create_bundle_demo工程 接下来我们就可以直接对这个工程进行maven（mvn eclipse:eclipse）使其成为一个eclipse可以识别的工程，来用eclipse对其进行开发了。 当开发完毕后，我们就可以直接利用之前的pax:provision命令来启动这个环境的工程，pax会依次由test目录下的pom来检索相应的bundle工程，按照各个bundle中pom的配置对其进行OSGI的bundle打包工作，打成bundle后再将其部署到启动的OSGI环境中去。 现在，我们看看我们刚才生成的那个工程里的POM文件 xml 代码 xml version='1.0' encoding='UTF-8' ?> ../poms/compiled/relativePath> org.ops4j.example.test.buildgroupId> compile-bundleartifactId> 0.1.0-SNAPSHOTversion> parent> com.zhoufu.demobundle.package> properties> 4.0.0modelVersion> org.ops4j.example.test.bundlesgroupId> create_bundle_demoartifactId> 1.0version> ${project.artifactId} [${bundle.package}]name> bundlepackaging> maven-dependency-pluginartifactId> plugin> org.ops4j.pax.mavengroupId> maven-bundle-pluginartifactId> plugin> org.ops4j.pax.constructgroupId> maven-pax-pluginartifactId> plugin> plugins> build> project>非常好，当然，这只是个初始的POM，随着bundle的开发，这里面肯定有一些关于bundle的依赖配置，需要增加到MANIFAST.MF文件中去，那么怎么告诉pax打包的时候生成什么样的MANIFAST.MF文件呢，其实也就是在org.ops4j.pax.maven这个plugin的配置段里进行配置好了。如下，我从项目中，提取了一段配置的模板，大家可以参考参考
