因为有DUDU~所以我们一群幸福的Blogger。
周六www.blogjava.net早上10：00准时停止服务了~，原本我以为可以安安静静的等待重新恢复，但是我错了，从昨天开始就出现了焦躁不安的情绪，总感觉这个世界此时好像少了什么东西，每次打开马桶都习惯的点击一下自己的Blog连接，但是在过去的几十个小时里~我的无法平静！
今天一大早起来，下了一个Eclipse3.3RC4玩，发现Eclipse团队修改掉了过去的BUG，而且在Eclipse3.3里面为RCP开发提供了更好的东东~本想开Blog记录一下，但是转念一下，关了！只能等待，无聊间，继续玩我的大富翁（寻找一下炒股的快感！）一口气玩到现在。上网看看，发现Blog已经搞好了~dudu就是dudu，说话算数！随性写文一篇，纪念一下“关站2日门”~
Eclipse3.3的新特性，待明日补上！
摘要: 感谢大家最近对本系列的关注和评论，我会继续完善内容，并且总结教训写出更好的东东来。 今天谈谈最近在研究的RCP安全模型，其实RCP在诞生之初就是建立在一个非常鲁棒的框架之上的---OSGi，它不但有全新的概念，全新的思路，全新的热插拔技术，还有非常好的安全模型（equinox security 项目好像还在孵化中）... 阅读全文
感谢大家对上一篇文章的拍砖，引起的反响不小，目的达到了~
，希望可以继续板儿砖横飞！
今天来说说第三方JAR包的引入。RCP开发（或者plugin开发）中最让人头疼就是第三方JAR包的引入了，很多初学的朋友常常头疼，介绍的文章也不少了，如果搞不定，自己google一下就可以了。
为什么第三方JAR包会引发如此众多的问题，其实并不是Eclipse的错，而是先入为主的错。如果你一开始就就接触Eclipse开发，以后再做不同java开发，你就会觉得java的类加载机制是变态了~Eclipse的类加载机制是基于OGSI的实现，它完成了插件的独立加载和独立维护，正是因为这种变态的类加载机制，才有了我们头大的第三方jar包的问题，也正是这种伟大的类加载机制，才有了即插即用的思路的诞生。
大多数简单的RCP项目都是将所有的JAR包放入本地项目中，然后直接进引入项目路径，就开始整了，对于小的应用，或者开发人员少的情况下，这样是可行的，也是便捷的~但是RCP的目标是大型的企业级应用，一个系统由十几个，几十个插件组成，是很正常的。所以就要求我们将RCP中所有用到的第三方JAR包统一管理，统一维护，给开发人员少一些烦恼。
思路有两种：
1.将JAR文件plugin样子包装，及新建Plug-in from existing jar archives 项目，然后选择JAR文件，再取消Unzip the jar archives into the project 选项，然后其它的插件依赖它就可以了。
2.新建一个不同插件项目，然后把第三方JAR包放入这个项目，然后引入到此项目中，在plugin.xml的runtime配置页的Exported Packages 选Add... 再选择要发布出去的包路径，然后其他的插件依赖它就可以了。
官方推荐的方式是第一种，个人认为第一种确实很好，可以非常好而且方便的维护第三方JAR包。但是我还是选择了第二种方式，理由是，配置文件读取的问题。
每一个插件文件都会维护一份属于自己的配置文件，只有这样才能做到自我独立。但是这两种方式都不能使其他插件项目的配置文件独立维护，原因就是Eclipse那讨厌又强大的类加载机制。
使用第一种方式，配置文件必须放在你记载的进来的JAR包的里面，这样Eclipse类加载机才会加载并处理，除非选择了Unzip the jar archives into the project 选项，并把配置文件和一堆的class文件放在同一目录下类加载机才能发现。我想这种方式谁都不会喜欢，要么就是我们要创造自己的JAR包，要么工作台遍布了各种各样来自世界各地的class文件。
使用第二种方式，是通过运行时将需要发布出来供别人依赖的package发布出来，而配置文件则需要放在此插件项目中。相对而言，这种比上一种有很大的好处，而且也不是那么难维护。
以上只是自己项目中的一些总结，关于第三方JAR包的问题，我查了很多资料，好像逃不过这三种方式（直接在项目中依赖算一种），不知道各位大侠还有没有更好的办法，即能处理好第三方JAR包，又能保持各个插件维护自己独立的配置文件？
有事没事写Blog吧～
写Blog的N个理由：
1.测试键盘的耐久程度；
2.锻炼一下自己的语言表达能力；
3.锻炼一下自己的耐性；
4.广交朋友；
5.发表一下自己的学习成果；
6.加深自己学习的印象；
7.记录一下自己的思想；
8.想像一下自己也是技术牛人；
9.给后人一些指点；
10.让寻觅的的老板们早点发现你；
11.少干点家务；
12.放送一下自己；
13.加个广告争点小钱；
... ...
想不出来了，头都大了～
RCP还是新兴的东西，大家都是用它做做小东东，所以在网上讨论RCP深度应用的文章还不多。
在此作文N篇阐述一下我在项目中的实现思路，欢迎大家拍砖。
首先看一下我们的项目的总体架构：
这个图谁都会画，就不说了，只是说明我们在用RCP而已。
再看看Client这层是怎么组成的：
依赖关系是自上而下的～，当然大家都需要依赖RCP-RUNNTIME本身。
jar plugin ---将第三方jar包包装成plugin样子，以供其他的插件依赖，解决了RCP项目对第三方包依赖麻烦的问题，例子：junit插件的实现；
DMP Platform ---DMP是我们产品的名字，所以，不要立即google，在这层我们抽象的定义出大量的公共的CoolBar以及MenuBar，都是尚未实现的，以待业务扩充之用，最重要的是在这层中我们集中处理权限问题，后面会说到；
业务组建（plugin）---其实就是针对于DMP Platform编写的一大堆的插件，而这些插件则是业务相对独立，这样就遵守了Eclipse的原则，所有东西都以插件形式提供的，也方便了我们以后对软件的定制化开发；
纵观国内外RCP的应用（国内本身就是很少），很少有RCP应用使用Eclipse的思想进行开发的，都是一个项目直接上～就一个UI层～什么都有！如果是这样，还不如用VC，VB更简单～
Eclipse RCP最好的应用还是Eclipse本身，Platform仅仅提供对文件的最简单的管理能力，而且定义一堆共用的Action，其他东西（JDT,ANT,JUNIT等等）都是以插件形式出现的～只有有了插件，才有了RCP业务动态扩充的动态组合的新理念。
今天在写RCP的基础运行插件的时候，发现一个非常有意思的问题：
我有两个插件A和B，A是RCP运行主插件，B是普通插件，A依赖于B存在并运行。当我把B打成JAR包，放到A下，做本地依赖的时候，那么Log4j的配置文件加载无误，但是这样是违反了Eclipse插件开发原则（Eclipse最小运行单位是插件）的；我把A和B通过feature进行关联，然后在A中依赖B插件，通过product文件启动A插件的时候，发现B插件无法加载Log4j的配置文件... ...
很郁闷的问题哦~为什么？
因为我一直在使用原来java的类加载机制思考问题，一个类加载机，将加载所有的Class~在Eclipse下则不是这样的，每一个类加载机只负责一个插件的内容加载~多个类加载机之间是没有关系的~
因此，每一个插件在类加载时都是独立的个体~所以每一个插件下面都需要自行增加一个Log4j配置文件，大家都独立维护自己的Log4j配置文件~唉，有一个配置文件泛滥的年代啊~
ps：
今天在Eclipse站上学习如何使用Maven2管理Eclipse plugin时，偶然google到了~Codehaus上已经有了maven2管理Eclipse plugin的插件了~
http://mojo.codehaus.org/pde-maven-plugin/index.html
真是踏破铁鞋无觅处，得来全不费工夫！
顺道说说Baidu，我baidu MOJO的时候，搜索结果80%竟然是MP3类的~我都晕倒了，我以为我开的是Mp3.baodu.com，百度现在是不是转行转作MP3了？