`
snoopy7713
  • 浏览: 1150404 次
  • 性别: Icon_minigender_2
  • 来自: 火星郊区
博客专栏
Group-logo
OSGi
浏览量:0
社区版块
存档分类
最新评论

maven-bundle-plugin

    博客分类:
  • OSGi
阅读更多

转载地址:http://victorhaw.blog.163.com/blog/static/9340346520099104921667/


之前的Opendoc中没有涉及过此部分的内容,maven又是现在非常流行的java的工具,再加上到目前为止搭建OSGi Maven开发和部署的环境还是比较的麻烦,觉得有必要写篇这样的blog,:),在这篇blog中来看下如何搭建一个比较好用的OSGi Maven开发和部署环境,看看我在搭建一个这样的环境中的痛苦历程。

首先说下我期望的OSGi Maven开发/部署的环境:

1、META-INF中的manifest.mf文件可以自己控制;
      Eclipse 对插件工程的开发支持的很好了,在IDE中可以很方便的去修改这个manifest.mf,所以还是自己控制更爽,当然,打包的时候需要打入自己控制的这个manifest.mf。
2、在mvn eclipse:eclipse生成的.classpath中,能够不把所依赖的bundle的jar包放进去;
      因为在OSGi环境中,已经不再通过直接在project的classpath中依赖其他bundle的jar了来调用其他bundle中的 package,而是通过在manifest.mf中增加imp

ort- package这样的方式,所以不能再把依赖的bundle的jar打到 classpath里了,否则会很奇怪,当然,这也源于eclipse有个很好的插件开发环境,让你可以在不依赖bundle jar的情况下直接写依赖其他bundle的package的代码。
3、在mvn clean package的时候能够把需要依赖的jar打到bundle jar中,并和META-INF/Manifest.mf文件中的Bundle-Classpath是匹配的;
      在某些bundle中可能会依赖一些jar,在META-INF中通常会去指定依赖的这些jar,放入bundle-classpath中,因此要求在打包的时候能够把这些依赖的jar打入相应的路径下。

说完想法后,首先想到的是在OSGi界中支持maven环境的大名鼎鼎的maven-bundle-plugin(
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html ),maven-bundle-plugin基于Peter写的bnd实现,不说废话了,按照自己期望的环境来使用maven-bundle-plugin进行搭建:

步骤一

按照上面页面的指导,在pom.xml中增加maven-bundle-plugin先,接着按照自己的想法,要自己控制manifest.mf,于是在plugin的configuration中增加:
<_include>META-INF/MANIFEST.MF</_include>
满心欢喜的等待着完美的结果,可惜....不如人意呀,打包出来的jar里面的MANIFEST.MF已经物是人非了,完全不是自己控制的那个,插件给你 自动的加上了一堆的imp
ort-package、private-package、export-package,我知道这个插件是基于bnd来写的, 但没想到竟然连自己控制的权力都不给我了,完全仍然是通过bnd来计算出imp ort-package、private-package什么的;

步骤二

好,在伤心过后接着仔细看,还好,在plugin的configuration中可以自己指定export-package、private- package这些,于是继续欣喜的使用,这两个倒是控制住了,但....imp
ort- package自己是不能控制的,这个是不行的,这样就导致了必 须同时自己维护pom.xml以及project中的META-INF/MANIFEST.MF,让它们保持一致,否则可能导致打出来的包和你在 project中运行的表现不一致,并且bnd计算出来的imp ort-package并不是我想要的,有点太复杂了,还是自己控制比较好;

步骤三

伤心到极点了,其实到目前为止,已经可以确定maven-bundle-plugin,也是OSGi maven中唯一的插件,不能满足我的需求,不过还是继续看看这个插件其他方面的表现,惊喜的发现有一点倒是做的不错的,它支持一个<Embed-Dependency> *;scope=compile|runtime</Embed-Dependency>,有了这个标签后,它可以直接把依赖的jar打入bundle jar包中,并且相应的自动在bundle-classpath中加上了,这点倒是不错的,看起来与我期望的环境的第3点是比较匹配的,可惜了。
还有就是,很当然的,它没法做到控制mvn eclipse:eclipse时生成的.classpath不包含bundle jar的引用。

按照上面的三个步骤,总结下,有些时候智能是好事,但maven-bundle-plugin就是过于智能了,为什么不给点权力给使用者呢,因此这个插件 要提升到完全可用的情况的话,还需要提供下让使用者自己控制MANIFEST.MF的权力,相信这点要做到并不困难,而且做到这点后基本也就可以使用了。

继续寻找,于是静心分析了下自己的需求,貌似可以自己通过maven现有的几个插件来达成自己的愿望,于是开始了组合拳:
1、MANIFEST.MF文件自己控制
     不就是要自己控制这个文件嘛,OK,干脆,就只用maven-jar-plugin,这个插件允许指定所使用的MANIFEST.MF文件,于是,尝试着在这个plugin的configuration中增加:
     <archive>
         <manifestFile>META-INF/MANIFEST.MF</manifestFile>
     </archive>
     恩,很顺利,开门红呀,打出来的jar包中的MANIFEST.MF文件就是自己的那个。
2、mvn eclipse:eclipse生成的.classpath中要去掉bundle jar的依赖
      对于我这么一个对maven不是那么熟悉的人来讲,这个有点复杂,于是不断的google,甚至是翻看了maven-eclipse-plugin的源码...
      最终终于功夫不负有心人,找到一个简单的办法:
      首先将工程方式指定为pde,也就是eclipse插件工程,在maven-eclipse-plugin的configuration配置中增加<pde>true</pde>;
      然后在pom.xml中将不希望生成到.classpath中依赖的scope指定为provided;
      心惊胆战的开始运行mvn eclipse:eclipse,OH YEAH!,成功!
      ps: 另外也可以通过在maven-eclipse-plugin的configuration中增加exclude配置,来将某些依赖从.classpath中去掉,当然,这方法没有上面的易用。
3、在mvn clean package的时候能够把需要依赖的jar打到bundle jar中,并和META-INF/Manifest.mf文件中的Bundle-Classpath是匹配的;
      恩,这点,印象中貌似maven是有支持的,于是继续开始找,终于找到了maven- dependency-plugin(之前还找到了一个maven-shade-plugin,也很帅,不过不满足需求),通过这个插件可以把需要的依赖 的jar都复制到某个指定的目录中去,但记得把这个指定的目录加入到maven-jar-plugin的resources目录里面去,否则这些jar文 件是不会出现在你的bundle jar里的。

OK,通过上面这套组合拳,终于达成了目的,看来有必要找个时间写个好用点的maven的OSGi插件,否则真的忒折腾了,上面这个方法仍然有几个痛苦的地方:
1、如果你的bundle中需要export其中依赖的lib的package的话;
     mvn eclipse:eclipse之后你会发现其他bundle即使import 了这个package,也会调用不到,这里的原因在于生成 的.classpath中所依赖的那个lib的exported属性没有设置为true,google了maven eclipse插件,貌似这是它的一个缺失的功能,因此在目前只能是mvn eclipse:eclipse后,再到build path里把这些lib exported出去。
2、还是得在插件的pom.xml中配置所依赖的其他的bundle;
     这是为了让你在mvn clean package的时候能通过,这点还是挺郁闷的,如果能自己去找到的话就好了(Felix构建bundle repo是有潜质做到这点的),:),这样导致了在每次在import package后,还得记得去修改了pom,否则的话在eclipse compile什么都正常,到了maven里就挂了。
因此,如果能解决上面两点的话,那将更加完美。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics