Equinox，我不想多做介绍，相信很多人都有所了解了，不了解的可具体去
www.eclipse.org/equinox
看看。
最近基于equinox做了一个系统，还是碰到了一些问题，当然也得到了在插件体系架构下的不少优点，在这里也做个总结。
总体而言，基于equinox做开发对于大多数java开发人员来说应该不会有太多改变的感觉，最多改变的感觉应该是带给设计师，设计师需要有发挥插件体系架构优点以及减少其带来的缺点的能力，^_^
1、部署不是很方便
equinox默认提供的是一个console端的插件部署管理，部署起来需要通过"install reference:file://"这样的方式来安装插件，不是特别的方便。
^_^，由于我当时使用的时候equinox还没提供osgi中httpservice的实现，便使用了oscar中提供的httpservice的实现，基于这个httpservice的实现写了一个web端的插件管理的工具，呵呵，将来整理后会将这个bundle公布出来，到时大家直接下载就可以用了。
在部署方面还有一个不方便的地方就是不能指定插件的启动顺序，现在equinox是通过config.ini中来实现插件启动顺序的控制的，这个在我的web端的插件管理工具中也提供直接，可直接设定插件的启动顺序。
2、Classpath的问题
这个问题是我在使用equinox时比较头疼的一个问题，我在bundle中使用了spring IoC container，而由于spring中使用的不是当前类的加载器，导致在加载配置文件的时候会出错，只得直接修改了spring中那些部分的代码，将其改为使用当前类的加载器。
在集成其他一些自己含有classpath的东西的时候也很容易出现这个问题。
虽然从原理上来讲这个是可以理解的，因为在插件体系结构中每个插件都拥有独立的插件类加载器，这个确实会对集成的有些东西产生影响，抑或我们应该理解为集成的那些东西在这方面设计有缺陷？
3、有利于面向接口编程的执行
这个应该说是属于插件体系结构的好处，每个插件可以控制自己对外所暴露的包，这个时候就可以只暴露接口所在的包，^_^，呵呵，面向接口的编程就这么被强制的执行了。
4、插件开发的IDE
这点是我觉得equinox的天然优势，拥有一个eclipse这么优秀的插件开发的IDE，^_^
支持了插件的调试...
我认为的最重要的一点是它解决了插件依赖的问题，通常在出现project依赖的时候我们都需要引用该project或是该project生成的jar，而在插件体系结构中只需要在插件文件中定义所依赖的包即可，这个就解决了去引用project那样方式引起整个项目工程包混乱和开发不便的现象。
5、插件的测试
这点我想也是大家很关心的，不过大家可以放心，基本没什么不同的，unit test继续使用Mock方式完成所测试的unit的外部依赖的部分，集成测试则需要启动equinox容器，这点应该没什么不能接受的。
6、Bundle和Service的定义
这个就是插件体系结构带来的一个挑战，如果准确的定义系统中的bundle和service是很关键的一个问题，这对于发挥插件体系结构的bundle级别、service级别的重用性至关重要，同时对于整个项目结构的清晰度也会产生很大的影响，形成bundle的清晰的service依赖结构。
7、面向服务的体系
我想这也同样是象equinox这样的插件框架引发使用者的思考，系统采用的应该是一种面向服务的体系，服务才是系统的核心，bundle只是一个管理器而已，这个时候怎么样设计出动态、松散耦合的服务体系是很关键的。
equinox一直都在发展之中，它的maillist一直就非常的热闹，而且现在对于osgi中的service它基本都实现了，也已经开始提供对于servlet container集成的支持，^_^，极度支持equinox，虽然它还需要不断的努力.....
可以看得出，经过我上面的总结，大家其实要担心的是引用一种新的体系结构带来的设计层面的变革，而不是开发实现层面，^_^
