New-->Plug-in Project

如果你的bundle在啟動和關閉的時候需要被通知，可以勾上Options中的第一個，實現BundleActivator介面，Finish後我們的第一個Bundle就建好了

Bundle中最重要的一個檔案就是bundle的描述檔案MANIFEST.MF，看下該檔案中的內容

Bundle-ManifestVersion

    該屬性頭告訴OSGi容器，本Bundle將遵循OSGi規範，數值2表示本Bundle和OSGi規範第4版本相容;如果該屬性的數值為1，那麼則表示本包和OSGi版本3或更早版本相容。

Bundle-Name

    該屬性頭為本Bundle定義了一個簡短的、可以閱讀的名稱;

Bundle-SymbolicName

    這個屬性頭為本Bundle定義了一個唯一的、非本地化的名字;當您需要從別的Bundles中訪問某一指定的Bundle時，您就要使用這個 名字。

Bundle-Version

　　該屬性頭給出了本Bundle的版本號。

Bundle-Activator

    該屬性頭給出了本Bundle中使用的監聽器類名字，這個屬性值是可選的。監聽器將對Activator中的start()和stop()方法 監聽。

Bundle-Vendor

該屬性頭是對本Bundle發行商的表述。

Bundle-RequiredExecutionEnvironment

    Bundle執行所依賴的環境

Import-Package

    定義bundle的匯入包。

Dependencies中新增bundle所依賴的bundle或所依賴的包

Runtime中設定該bundle匯出的包

Bundle匯出後其實就是一個jar檔案，這個jar檔案和普通的jar檔案唯一不同的地方就是Meta-inf目錄下的MANIFEST.MF檔案的內容，關於Bundle的所有資訊都在MANIFEST.MF中進行描述，在OSGI框架中對於每個Bundle採用的是獨立的classloader機制，這也就意味著不能採用傳統的如引用其他Bundle的工程來實現Bundle間的協作了，那麼在OSGI框架中Bundle之間是怎麼協作的呢，在OSGI框架中對於每個Bundle可以定義輸出的包以及引用的包，這樣在Bundle間就可以共享包中的類了，儘管這樣也可以直接實現簡單的Bundle的協作，但在OSGI框架中更加推薦的是採用Service的方式,每個Bundle可以通過BundleContext註冊對外提供的服務，同時也可以通過BundleContext來獲得需要引用的服務，採用Service-Oriented的方式可以使得對外提供的服務能夠更加的封閉，不需要為了使用別的Bundle提供的Service而做環境依賴等的設定，同時，Bundle還可以採用Require-Bundle的方式來直接引用其他的Bundle，不過不推薦使用這種方式，耦合度太高。

執行新建的bundle

把需要的bundle勾上，Run

bundle在其生命週期的6種狀態和OSGi控制命令臺的一些常用命令

INSTALLED

Bundle已經成功的安裝了。

RESOLVED

Bundle中所需要的類都已經可用了，RESOLVED狀態表明Bundle已經準備好了用於啟動或者說Bundle已被停止。

STARTING

Bundle正在啟動中，BundleActivator的start方法已經被呼叫，不過還沒返回。

ACTIVE

Bundle已啟動，並在執行中。

STOPPING

Bundle正在停止中，BundleActivator的stop方法已經被呼叫，不過還沒返回。

UNINSTALLED

Bundle已經被解除安裝了。

安裝Bundle

通過BundleContext的installBundle方法來安裝Bundle，在安裝前首先需要對Bundle進行校驗，導致Bundle安裝失敗的原因在之前Module Layer章節中已經描述過了，如校驗通過，OSGI框架中將安裝Bundle到系統中，此時OSGI框架會分配一個高於現在系統中所有的Bundle的ID給新的Bundle，安裝完畢後Bundle的狀態就變為INSTALLED了，同時會返回bundle物件，在Bundle安裝後就要使用bundle物件來管理Bundle的生命週期狀態了。

解析Bundle

Bundle安裝完畢後，OSGI框架將對Bundle進行解析，以檢測Bundle中的類依賴等是否正確，如有錯誤則仍然處於INSTALLED狀態，如成功Bundle的狀態則轉變為RESOLVED。

啟動Bundle

在啟動Bundle前需檢測Bundle的狀態，如Bundle狀態不為RESOLVED，那麼需要先解析Bundle，如啟動一個解析失敗的Bundle，則會丟擲BundleException，但此時Bundle的狀態仍然會被設定為ACTIVE；如Bundle的狀態已經是ACTIVE，那麼啟動Bundle對它不會產生任何影響。

通過BundleContext的getBundle方法可獲取指定Bundle ID的Bundle物件，在獲取到Bundle物件後可使用Bundle物件的start方法來啟動Bundle，此時會呼叫MANIFEST.MF中的Bundle-Activator屬性對應的BundleActivator類的start方法(如存在BundleActivator類)，在start方法執行的過程中Bundle的狀態為STARTING，當start方法執行完畢後Bundle的狀態轉變為ACTIVE，如start方法執行失敗，Bundle的狀態轉變為RESOLVED。

BundleActivator類是可以不需要的，建議不要在BundleActivator中初始化過多的東西，這樣會使得系統的啟動速度會變得很慢，同時也會消耗大量的記憶體，而且OSGI對於動態性的良好支援使得儘可以在需要的時候才去獲取所需的資源。

停止Bundle

通過BundleContext的getBundle方法可獲取指定Bundle ID的Bundle物件，在獲取到Bundle物件後可使用Bundle物件的stop方法來啟動Bundle，此時會呼叫MANIFEST.MF中的Bundle-Activator屬性對應的BundleActivator類的stop方法，在stop方法執行的過程中Bundle的狀態為STOPPING，當stop方法執行完畢後Bundle的狀態轉變為RESOLVED，如stop方法執行失敗，Bundle的狀態則繼續保留原狀態。

即使Bundle已經停止，其export的package仍然是可以使用的，這也就意味著可以執行RESOLVED狀態的Bundle中export package的類。

解除安裝Bundle

通過呼叫Bundle物件的uninstall方法可完成Bundle的解除安裝，此時Bundle的狀態轉變為UNINSTALLED。

即使Bundle已解除安裝，其export的package對於已經在使用的Bundle而言仍然是可用的，但對於新增的Bundle則不可使用已解除安裝的Bundle export的package。

Osgi命令控制檯常用命令

ss: 該命令顯示所有已安裝的Bundles及它們的狀態，它將顯示Bundle ID，Bundle狀態，Bundle的簡短名；  

start【bundleid】: 啟動對應id的Bundle 

stop【bundleid】: 停止對應id的Bundle 

update【bundleid】: 更新對應id的Bundle

install【bundleid】: 安裝對應id的Bundle 

uninstall【bundleid】: 解除安裝對應id的Bundle

exit: 退出osgi環境

refresh【bundleid】: 重新整理對應id的Bundle

ls：顯示所有services  如果沒有釋出service會顯示找不到該命令

ls –c 【bundleid】：顯示該bundle中所有釋出service的詳細資訊，對與unsatisfied的component查錯很有用