osgi bundle的编译时与运行时的依赖

bundle之间存在耦合，就必然存在依赖关系，由于osgi特殊的classloader组织结构，osgi的bundle之间及bundle内部的依赖关系稍微比传统java应用稍微复杂点。
   
首先，在传统java应用中，在运行时，大部分jar包都是由同一个classloader来加载，所以它们在编译时和运行时时的依赖关系基本上是一致的，也就是说你编译通过了，在运行时，如果将编译时需要的jar包加载了，就一般不会存在在ClassNotFound之类的问题，所以通常做传统java应用开发的开发人员不需要或较少理会“编译时”和“运行时”两个阶段。
   
而在osgi语境下，编译时依赖和运行时依赖通常存在较大差别。 假设我们以maven来管理bundle的工程项目。

首先，bundle的编译是和manifest.mf无关的，无论manifest.mf里作了任何设置，都只会被原样打包到目标bundle里，编译器根本不会去解析manifest.mf。bundle编译时只与maven里的pom指定的依赖相关，如果bundle里的代码中引用了第三方包，那么pom里就需要显式指定或隐式地继承对这个第三方包的依赖。否则就无法编译通过。

而在运行时，bundle的状态从installed,到resolved,再到active。在installed到resolved的迁移过程中，需要满足manifest.mf中的import-package的条件，也就是必须有其它bundle export出这些packages，否则无法resolved。所以，bundle的运行时的依赖首先就是由manifest.mf里的import-package指定了(Bundle-Required等项也限定了)。而这时，原来在maven的pom.xml里指定的依赖关系不会影响bundle的resolve过程。

从上面分析可知，bundle的编译时和运行时的依赖关系是有区别的。 如果我们在maven的pom.xml中指定了多余的依赖关系，一般并不影响bundle的编译(除非有包的冲突)。但如果在manifest.mf的import-package里指定了多余的package,就可能会导致bundle无法resolved。