OSGI项目持续集成(环境搭建, 编译和发布总结)

OSGI项目发布总结

1 概述

本文描述将OSGI平台(服务端)打包发布为独立运行的包, 从而脱离Eclipse的开发环境, 发布的方式有:

1.      采用手动的方式一步步的打包发布

2.      Eclipse环境下能够运行的Bundles工程, 必然MANIFEST.MF是OK的, 因此直接用Jar包发布(曾经选择BND这个工具让作者走了不少弯路).

 

进行一下友善的提示, OSGI开发带来的便利的同时, 最头疼得就是众多的插件, 在设计的时候, 必须有个分层的思想体现, 这样可以带来两个不错的收获:

1.      底层可重用

2.      避免插件之间的相互引用或者循环引用。

2 手动打包发布

该方式是比较直接和容易理解的方式

2.1    将所有的包导出为Jar

1.      点击File-> Export 出现选择界面

OSGI项目持续集成(环境搭建, 编译和发布总结)_第1张图片

2.      选择下图所示的选项, 然后进入Next Step

OSGI项目持续集成(环境搭建, 编译和发布总结)_第2张图片

3.      随后进入到导出选择框, 选择跟项目相关的Boundles, 这里Workspace的所有的项目, 都需要导出。 当然这里还没有包含其它的项目, 比如Jetty, Servlet 等, 这些第三方包的问题, 后面会进一步讨论。 填好导出的路径, 如下图所示:

OSGI项目持续集成(环境搭建, 编译和发布总结)_第3张图片

4.      点击Finish, Workspace的工程将全部导出

5.      另外上面提到不在Workspace, 但ISW所依赖的包, 也需要Copy到发布的目录中, 可以查看到ISW中依赖的内容包含(从Run Configuration):

 OSGI项目持续集成(环境搭建, 编译和发布总结)_第4张图片

6.      将4和5提到的所有的包进行安装.

 

install file:\E:\ISWRelease\osgi_release\workspace\com.XXXX.util.types_1.0.0.201

107111109.jar

7.      依次启动所有的包. 为了避免启动顺序有误, 需要按照以下步骤

a)       先启动系统需要的包

b)       再启动workspace 中开发的包(即我们自己开发的包)

                         i.              先启动底层的包

                       ii.              再启动上层的包, 按照MANIFEST.MF描述的文件启动

 

第六步和第七步异常蛋疼, 因为OSGI提示符下, 确实找不到一个合适的导入文本的功能, 一步步编写, 手酸眼疼。 因此需要做点改进,下一节,应运而生。

 

3 改进:自动安装

这种方式是上面手动发布方式的一种改良, 而且仅仅是对第六步骤和第七步骤的改良, 具体做法是:

1.      通过Config.ini文件进行安装和管理

2.      Java –jar org.osgi.XXXX.jar –console 命令回到指定的位置读取1中config.in文件.

 

具体如下:

1.      相对路径的设置, 将plugin分为osgi系统需要的插件(放置在osgi_plugins目录下)和ISW平台开发的插件(放置在isw_plugins目录下)

OSGI项目持续集成(环境搭建, 编译和发布总结)_第5张图片

2.      config.ini的编写(注意换行是怎么做的):

 OSGI项目持续集成(环境搭建, 编译和发布总结)_第6张图片

另外依赖关系很重要, 一般而言,没有依赖的先加载, 有依赖关系的后加载。而启动的Start Level 尽情忽视之。

参考文章在此 原理也说得很明白, 因此无需再费口舌。

 

4 再改进: 自动打包

其实再怎么变动, 不争的事实是, 还是有人工的参与, 因为第一步打包发布, 需要用wizard去导出, 这样无法实现自动化过程, 因此这里需要将通过wizard导出OSGI包的步骤完全通过脚本搞定。 N多参考书中提到一个叫做BND的工具, 有兴趣可以看看其官网, 鉴于其不给力的官方说明文档, 哥从来没有成功的用过。何况还要引入BND的包。增加了项目的管理复杂度。 所以, 何不用一下ANT 自带的jar命令进行打包。

整个过程只不过以下的脚本:

<jar destfile="${releaseJar}" basedir="${binPath}" manifest="${basedir}/${projectname}/META-INF/MANIFEST.MF">

       </jar>

表示压力不大, 但有时候会需要一些配置文件放到这个包中, 比如根目录下有个lib要打包进来, 此时应该这样处理:

<jar destfile="${releaseJar}" basedir="${binPath}" manifest="${basedir}/${projectname}/META-INF/MANIFEST.MF">

<fileset dir="${basedir}/${projectname}" includes="**\*.jar"/> 

       </jar>

为了避免一个NB的NoClassDefFoundError问题, 大部分的情况, 需要用到的第三方包, 都会捆绑成一个Bundle进行管理。 详细参考学习手册.

       上述只是讲明了一个OSGI包的发布, 选择OSGI意味着选择了众多的插件工程, 所以, 整个工程的持续构建, 还需要一点技巧。作者的方式是:

1.      每个插件的ANT构建脚本可以独立运行

2.      用一个统一的Shell脚本, 将上述各个ANT构建脚本运行起来。

这样的方式, 细节控制留给各个插件, 大局控制交给Shell脚本。层次比较分明,典型的金字塔式的组织模式,也是我一直推荐《金字塔原理》这本书的原因。

你可能感兴趣的:(OSGI项目持续集成(环境搭建, 编译和发布总结))