EclipseCon2006已经结束一段时间了，最近才抽出时间去down下相关感兴趣的PPT来看看，受益不少，N多大师的演讲另人拍案叫绝，不过也有几个PPT让我看的有所疑问，摘录几个PPT的读后感，^_^
1、Best Practices for Programming Eclipse and OSGi
这个PPT是equinox team leader Jeff的大作，^_^，非常的不错，点出了Equinox中的两个重点，虽然这和PPT的名字有所不同：
Modularity
在equinox中可以采用两种方式来实现这点，分别是Require-Bundle和Import-Package的方式，就像Jeff在PPT中所说一样，Require-Bundle适合用于需要引用其他Bundle中的资源的情况，但它就使得bundle产生了紧耦合，所以推荐使用Import-Package，Import-Package保证了松耦合，在实际的使用中来看，Import-Package能够使得面向接口的编程得以强制进行，当然，不是说require-bundle就一无是处了，^_^
Collaboration
在松散型的插件架构体系中，插件如何进行协作无疑是最为关注的重点， Jeff在PPT中提到了在equinox中可以采用三种方式来实现协作，分别为Extension Registry、Service Registry和Declarative Services，对Jeff把Extension Registry列在Collaboration这里我表示有些疑问，我认为Extension Registry和Collaboration关注的完全是两个层面，一个关注的是扩展，一个关注的是协作，Extension Registry不用多做介绍，在Equinox目前的版本中Declarative Service Implemention并没有列入release阶段，不过以Jeff在PPT的介绍来说非常吸引人，特别是这句"similar to Spring"，^_^，不过以我对之前Osgi R4的Declarative Service的了解来说，我认为它仅仅是IoC Type1而已，但如果象Jeff所说的这样的话那Declarative Service真的非常吸引人了，之前在equinox中都是使用Service Registry的方式来实现bundles的协作，痛苦呀，^_^，等试用了Declarative Service再行评价。
如感兴趣，可到http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=185下载此PPT。
2、Beyond Code Reuse
这个PPT中总结了一些Eclipse带给我们超越代码复用级别的思考，总结的非常好：
Modularize your applications
Eclipse让我们看到了如何去模块化的设计应用系统，最重要的几点就在于定义组件和API以及管理模块间的依赖，方式在1中的PPT的Modularity中有所提及。
Separate UI and core modules
这点如果你阅读过《Contributing to Eclipse》就明白了，在eclipse中有个重要的设计模式，称为Adapative Interface/Class，^_^，可以合理的将Core Model Object扩展为UI Model Object而不造成污染....
Design for extensibility
Eclipse的扩展性没什么说的，^_^，都是通过Extension Points的方式来实现，这点在自己设计系统中也是值得学习的，保持模块的扩展性。
Build to last
这点可用于保证API的稳定。
Adopt "The Eclipse Way"
Eclipse采用的一些好的实践，如日构建、集成构建和发布构建、单元测试、每周的计划、6周为一里程碑、时刻保持release版本、从里程碑版本中得到反馈等等，记得以前好像有个专门的这样的PPT....
如感兴趣，可到http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=123下载此PPT。
3、From Osgi R3 to Eclipse and Equinox
对这个PPT中的一些观点非常的不认同，在这个PPT中作者首先定义了两个名词：
BAPM: Osgi R3 Bundle Activator Programming Model
HPM: Eclipse Extension Points & Osgi R4 Declarative Services Programming Model
作者对这两种方式进行了一系列比较，他认为：
BAPM
更简单
有工具可支持校验等
允许使用纯pojos来实现业务逻辑处理
更为灵活(在重构和测试方面)
HPM
复杂
DS没有工具的支持
Extension Points的概念太复杂
将业务逻辑处理分解到Eclipse和Equinox的API中去实现
在大型系统方面更为高效(超过1000个的插件)
不确定的功能特性方面支持
BAPM更为简单我表示一定程度上的认同，毕竟Declarative Service是需要配置的，但对于BAPM允许使用纯pojos来实现业务逻辑，而HPM不支持的观点我表示怀疑，在这点上如果DS象Jeff所说可以实现setter DI的话，那么不用说，HPM自然可以使用纯Pojos来实现业务逻辑，而BAPM呢，除非能够在activator中完成plugin中各个需要外部service类的初始化，否则，就没法pojo了，就象嵌入一个web action在一个plugin中，这个时候是不能在activator中去初始化这个action的，那么何来pojo呢，^_^，同样的疑问就可以被应用在作者认为的BAPM更为灵活的观点上。
如感兴趣，可到http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=366下载此PPT。
4、Extending Eclipse's Plug-in Concept to the SOA World
这个PPT表达了怎么样将eclipse的plugin概念调整为适应SOA体系的观点，在这个观点上，我觉得OSGI本身其实就是个很好的服务体系的架构，甚至强过SOA，不过他们各自的关注点有所不同，所以也没什么好完全去比较的。
如感兴趣，可到http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=145下载此PPT。
^_^，以上是看了部分的PPT的一些看法，在这次EclipseCon 2006上有非常多的优秀的PPT，象OSGi™ Component Programming等等，可以到这里找自己感兴趣的PPT下载：
http://www.eclipsecon.org/2006/Sub.do?id=all