因為有DUDU~所以我們一群幸福的Blogger。
周六www.aygfsteel.com早上10：00準時停止服務(wù)了~，原本我以為可以安安靜靜的等待重新恢復(fù)，但是我錯了，從昨天開始就出現(xiàn)了焦躁不安的情緒，總感覺這個世界此時好像少了什么東西，每次打開馬桶都習慣的點擊一下自己的Blog連接，但是在過去的幾十個小時里~我的無法平靜！
今天一大早起來，下了一個Eclipse3.3RC4玩，發(fā)現(xiàn)Eclipse團隊修改掉了過去的BUG，而且在Eclipse3.3里面為RCP開發(fā)提供了更好的東東~本想開Blog記錄一下，但是轉(zhuǎn)念一下，關(guān)了！只能等待，無聊間，繼續(xù)玩我的大富翁（尋找一下炒股的快感?。┮豢跉馔娴浆F(xiàn)在。上網(wǎng)看看，發(fā)現(xiàn)Blog已經(jīng)搞好了~dudu就是dudu，說話算數(shù)！隨性寫文一篇，紀念一下“關(guān)站2日門”~
Eclipse3.3的新特性，待明日補上！
摘要: 感謝大家最近對本系列的關(guān)注和評論，我會繼續(xù)完善內(nèi)容，并且總結(jié)教訓(xùn)寫出更好的東東來。 今天談?wù)勛罱谘芯康腞CP安全模型，其實RCP在誕生之初就是建立在一個非常魯棒的框架之上的---OSGi，它不但有全新的概念，全新的思路，全新的熱插拔技術(shù)，還有非常好的安全模型（equinox security 項目好像還在孵化中）... 閱讀全文
感謝大家對上一篇文章的拍磚，引起的反響不小，目的達到了~
，希望可以繼續(xù)板兒磚橫飛！
今天來說說第三方JAR包的引入。RCP開發(fā)（或者plugin開發(fā)）中最讓人頭疼就是第三方JAR包的引入了，很多初學(xué)的朋友常常頭疼，介紹的文章也不少了，如果搞不定，自己google一下就可以了。
為什么第三方JAR包會引發(fā)如此眾多的問題，其實并不是Eclipse的錯，而是先入為主的錯。如果你一開始就就接觸Eclipse開發(fā)，以后再做不同java開發(fā)，你就會覺得java的類加載機制是變態(tài)了~Eclipse的類加載機制是基于OGSI的實現(xiàn)，它完成了插件的獨立加載和獨立維護，正是因為這種變態(tài)的類加載機制，才有了我們頭大的第三方j(luò)ar包的問題，也正是這種偉大的類加載機制，才有了即插即用的思路的誕生。
大多數(shù)簡單的RCP項目都是將所有的JAR包放入本地項目中，然后直接進引入項目路徑，就開始整了，對于小的應(yīng)用，或者開發(fā)人員少的情況下，這樣是可行的，也是便捷的~但是RCP的目標是大型的企業(yè)級應(yīng)用，一個系統(tǒng)由十幾個，幾十個插件組成，是很正常的。所以就要求我們將RCP中所有用到的第三方JAR包統(tǒng)一管理，統(tǒng)一維護，給開發(fā)人員少一些煩惱。
思路有兩種：
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... 再選擇要發(fā)布出去的包路徑，然后其他的插件依賴它就可以了。
官方推薦的方式是第一種，個人認為第一種確實很好，可以非常好而且方便的維護第三方JAR包。但是我還是選擇了第二種方式，理由是，配置文件讀取的問題。
每一個插件文件都會維護一份屬于自己的配置文件，只有這樣才能做到自我獨立。但是這兩種方式都不能使其他插件項目的配置文件獨立維護，原因就是Eclipse那討厭又強大的類加載機制。
使用第一種方式，配置文件必須放在你記載的進來的JAR包的里面，這樣Eclipse類加載機才會加載并處理，除非選擇了Unzip the jar archives into the project 選項，并把配置文件和一堆的class文件放在同一目錄下類加載機才能發(fā)現(xiàn)。我想這種方式誰都不會喜歡，要么就是我們要創(chuàng)造自己的JAR包，要么工作臺遍布了各種各樣來自世界各地的class文件。
使用第二種方式，是通過運行時將需要發(fā)布出來供別人依賴的package發(fā)布出來，而配置文件則需要放在此插件項目中。相對而言，這種比上一種有很大的好處，而且也不是那么難維護。
以上只是自己項目中的一些總結(jié)，關(guān)于第三方JAR包的問題，我查了很多資料，好像逃不過這三種方式（直接在項目中依賴算一種），不知道各位大俠還有沒有更好的辦法，即能處理好第三方JAR包，又能保持各個插件維護自己獨立的配置文件？
有事沒事寫B(tài)log吧～
寫B(tài)log的N個理由：
1.測試鍵盤的耐久程度；
2.鍛煉一下自己的語言表達能力；
3.鍛煉一下自己的耐性；
4.廣交朋友；
5.發(fā)表一下自己的學(xué)習成果；
6.加深自己學(xué)習的印象；
7.記錄一下自己的思想；
8.想像一下自己也是技術(shù)牛人；
9.給后人一些指點；
10.讓尋覓的的老板們早點發(fā)現(xiàn)你；
11.少干點家務(wù)；
12.放送一下自己；
13.加個廣告爭點小錢；
... ...
想不出來了，頭都大了～
RCP還是新興的東西，大家都是用它做做小東東，所以在網(wǎng)上討論RCP深度應(yīng)用的文章還不多。
在此作文N篇闡述一下我在項目中的實現(xiàn)思路，歡迎大家拍磚。
首先看一下我們的項目的總體架構(gòu)：
這個圖誰都會畫，就不說了，只是說明我們在用RCP而已。
再看看Client這層是怎么組成的：
依賴關(guān)系是自上而下的～，當然大家都需要依賴RCP-RUNNTIME本身。
jar plugin ---將第三方j(luò)ar包包裝成plugin樣子，以供其他的插件依賴，解決了RCP項目對第三方包依賴麻煩的問題，例子：junit插件的實現(xiàn)；
DMP Platform ---DMP是我們產(chǎn)品的名字，所以，不要立即google，在這層我們抽象的定義出大量的公共的CoolBar以及MenuBar，都是尚未實現(xiàn)的，以待業(yè)務(wù)擴充之用，最重要的是在這層中我們集中處理權(quán)限問題，后面會說到；
業(yè)務(wù)組建（plugin）---其實就是針對于DMP Platform編寫的一大堆的插件，而這些插件則是業(yè)務(wù)相對獨立，這樣就遵守了Eclipse的原則，所有東西都以插件形式提供的，也方便了我們以后對軟件的定制化開發(fā)；
縱觀國內(nèi)外RCP的應(yīng)用（國內(nèi)本身就是很少），很少有RCP應(yīng)用使用Eclipse的思想進行開發(fā)的，都是一個項目直接上～就一個UI層～什么都有！如果是這樣，還不如用VC，VB更簡單～
Eclipse RCP最好的應(yīng)用還是Eclipse本身，Platform僅僅提供對文件的最簡單的管理能力，而且定義一堆共用的Action，其他東西（JDT,ANT,JUNIT等等）都是以插件形式出現(xiàn)的～只有有了插件，才有了RCP業(yè)務(wù)動態(tài)擴充的動態(tài)組合的新理念。
今天在寫RCP的基礎(chǔ)運行插件的時候，發(fā)現(xiàn)一個非常有意思的問題：
我有兩個插件A和B，A是RCP運行主插件，B是普通插件，A依賴于B存在并運行。當我把B打成JAR包，放到A下，做本地依賴的時候，那么Log4j的配置文件加載無誤，但是這樣是違反了Eclipse插件開發(fā)原則（Eclipse最小運行單位是插件）的；我把A和B通過feature進行關(guān)聯(lián)，然后在A中依賴B插件，通過product文件啟動A插件的時候，發(fā)現(xiàn)B插件無法加載Log4j的配置文件... ...
很郁悶的問題哦~為什么？
因為我一直在使用原來java的類加載機制思考問題，一個類加載機，將加載所有的Class~在Eclipse下則不是這樣的，每一個類加載機只負責一個插件的內(nèi)容加載~多個類加載機之間是沒有關(guān)系的~
因此，每一個插件在類加載時都是獨立的個體~所以每一個插件下面都需要自行增加一個Log4j配置文件，大家都獨立維護自己的Log4j配置文件~唉，有一個配置文件泛濫的年代啊~
ps：
今天在Eclipse站上學(xué)習如何使用Maven2管理Eclipse plugin時，偶然google到了~Codehaus上已經(jīng)有了maven2管理Eclipse plugin的插件了~
http://mojo.codehaus.org/pde-maven-plugin/index.html
真是踏破鐵鞋無覓處，得來全不費工夫！
順道說說Baidu，我baidu MOJO的時候，搜索結(jié)果80%竟然是MP3類的~我都暈倒了，我以為我開的是Mp3.baodu.com，百度現(xiàn)在是不是轉(zhuǎn)行轉(zhuǎn)作MP3了？