如何使用Eclipse 功能部件來定制Eclipse 行為
構建一個插件是很有趣的：您開始編寫代碼並創建您想要的工具。把插件拷貝到 Eclipse 或一個基於 Eclipse 的產品中的 \plupgins 目錄下，這個插件在 Eclipse 運行期環境中就可以使用了。當再一次使用 Eclipse 的時候，插件將被找到，而且經過平台的啟動處理，它在運行期配置中將是可用的。
但是誰知道或者關心您的插件加入了進來？用戶可以明白您提供的是什麼工具嗎？他們可以通過 Eclipse 來禁用、修補或者管理您的組件嗎？答案顯然是否定的。插件本身僅僅是一個插件，而不是與 Eclipse 平台完全集成的組件。
功能部件包裝插件
如果沒有功能部件，插件是難以駕馭的，通俗地說，不屬於功能部件的插件是未被管理的插件。Eclipse 平台的啟動過程包括一個配置的步驟。如果一個新的插件被拷貝到 \plugins 目錄，或者以其他方式使 Eclipse 在啟動的時候可以找到，配置過程會發現它，但只是通過將新插件的 splash 圖標閃爍兩次來通知您。Eclipse 之所以會發現新的插件，是因為存貯在 \.metadate\.config\platform 中的當前工作區的配置校驗和發生了變化；由於您沒有向平台提供一個可以引導用戶做出配置修改的功能部件，Eclipse 也只能是通過 splash-flash來提示這一變化。將您的插件打包為一個（或兩個）功能部件，您將獲得如下好處：
在 Eclipse 的配置過程中列出您的組件（在 feature.xml 文件中）所要求的先決條件
使您的組件可以作為 Eclipse 配置的活動部分來管理
創建標記信息，讓使用那些使用運行期環境的用戶可以識別您的組件，並通過一個歡迎頁面來告知用戶您的功能部件所提供的功能（在關聯到您的功能部件的 welcome.xml 文件中）
用 Eclipse 更新管理器可以對您的組件進行修改
不要等到您的插件開發完成後再打包為功能部件。反映在功能部件定義中的設計結果會影響您如何構建您的插件。例如，大多數的 Eclipse 組件都有 UI 功能部件和核心（不是 UI）功能部件。如果您的插件沒有按這種方法進行劃分，您可能會馬上考慮重新設計它們。功能部件也可以用來自動編譯處理被引用的插件。
主要功能部件標識一個產品（但是您有控制權）
雖然功能部件很多，但是當您啟動 Eclipse 的時候，只有一個功能部件處於控制之下。這個主要功能部件決定了產品的標識和其他運行期行為，包括確定名字和與運行期平台相關聯的圖示，以及對所有插件默認屬性值的重新定義選項。在後面的 定義您自己的全局屬性中可以看到，這個功能強大的選項使您可以定制您自己的 Eclipse 設置。
功能部件構建插件（如果您允許它們）
插件開發環境（PDE）可以自動完成為完整的運行期環境准備功能部件和插件的大部分工作。參見 Eclipse.org 中文章的討論 "PDE 生成插件"。這些基本的步驟在The Java Developer's Guide to Eclipse中也曾作為一個練習涉及到，遵循那個練習您可以構建並標識您已有的插件。可以說如果您有一個功能部件，並且了解 PDE 如何幫助您構建插件和功能部件，您就可以構建一個功能部件，然後讓它去同時構建所有相關的插件。構建控制策略（bin.excludes 與 bin.includes）將在後面的 使用 PDE 構建功能部件的策略中討論。這些策略是對 Eclipse.org 文章以及The Java Developer's Guide to Eclipse一書的補充。
平台配置管理
理解功能部件所需要條件有助於理解它們如何對活動配置中可用的內容進行管理。
啟動過程
如果是一個剛解壓縮的 Eclipse 平台，那麼當您啟動 eclipse.exe 的時候將會發生：
安裝可能已經完成
如果一個工作區已經存在，那麼會有一個 .metadata\.config\platform.cfg 配置文件。
如果您是以常規方式安裝 Eclipse，您得運行 eclipse -initialize 命令來生成一個默認的初始化配置文件，放置在 eclipse\.config 目錄下。這樣當 Eclipse 以新的工作區啟動時不再出現 Completing the install的圖示。
找到 Java 運行期環境（JRE）。默認情況下，Eclipse 首先查找 exlipse\jre 子目錄。如果沒有找到，Eclipse 將查找在系統中注冊的 Java 運行期環境。
注意：-vm dir-location 參數可以用到指定其他的 JRE。
配置被作為新的工作區的一部分創建出來。新的工作區通常沒有任何的配置，所以您會在真正的 splash 圖標之前看到一個圖標，通知您安裝設置完成。
處理那些注冊到 Eclipse 的功能部件和插件，並創建在後面將會用於檢測變化的校驗和。這些功能部件和插件或者位於當前的 eclipse\features 目錄和 eclipse\plugins 目錄下，或者位於由鏈接文件指定的 eclipse\... 目錄結構中。
一旦 Eclipse 啟動，活動配置定義將包含在 .metadata\.config\platform.cfg 文件中。
鏈接文件如何擴展一個 Eclipse 安裝設置
如果您已經使用了一段時間的 Eclipse 或者在您的配置中添加了哪怕只是一個新的插件，您肯定知道 Eclipse 是到 eclipse\features 目錄和 eclipse\plugins 目錄下去查找功能部件和插件的。不過您是否知道，Eclipse 也會到文件系統的其他位置去查找功能部件和插件？如果在 eclipse\links 目錄下存在格式正確的鏈接文件，那麼這些文件會被處理，相關聯的功能部件和插件（包括沒有相關功能部件的插件）在運行期配置中都會是可用的。
一個鏈接文件只是一個命名為 id.link 的任意文件，在這裡 id 通常是正在被引用的根功能部件的 id。您可以在鏈接文件目標中定義不只一個功能部件，並且名字命名為 foo.link 也是可以接受的。給出一個包含如下內容的鏈接文件：
path=E:/Eclipse-2.1.1/installedFeatures/Examples
Eclipse 將會到指定的目錄下去查找 eclipse\features 目錄和 eclipse\plugins 目錄，看是否有合法的功能部件和（或）插件。也就是說，目標目錄必須包含一個 \eclipse 目錄。如果找到，附加的功能部件和插件在運行期配置是將是可用的，如果鏈接文件是在工作區創建之後添加的，附加的功能部件和插件會作為新的 配置變更 來處理。
使用鏈接文件來定制您自己的 Eclipse 安裝設置的策略將在本文稍後的 使用鏈接文件管理 Eclipse 安裝設置中進行討論。
配置更新――添加一個功能部件
如果一個新的功能部件及所用到的插件已經添加到已有的 \features 目錄和 \plugins 目錄下，或者通過一個鏈接文件注冊到 Eclipse，校驗和的變化將觸發配置處理過程。這個處理在一個簡單的 splash-flash之後進行。新的功能部件作為一個配置變更來處理，並且顯示出一個配置變更的對話框。
例如，如果您打開一個標准的 Eclipse 解壓縮環境的工作區，而後找到了 Eclipse Examples，您把它解壓縮到與 Eclipse 同樣的目錄樹中或者添加了一個鏈接文件來指明這個例子解壓縮到了何處，將會出現一個如圖1所示的對話框。
圖 1. 配置變更對話框
所以，如果您看到類似於這樣的一個對話框，那是因為在您運行一個安裝配置程序的時，您自己或者其他人修改了 Eclipse 的配置，而平台發現了新的或者更新過的可用功能部件。如果條目可以被選中，您可以將這個變化添加到您當前的配置中。如果條目被禁用，說明存在配置上的問題，這個功能部件不能被添加進來。按下 Error Details 按鈕可以查看有關配置問題的信息。
配置管理注解：
存在未決變更並不意味著您不得不馬上接受它們，在相當一段時間內您完全可以不去理會它們，只需要取消對條目的選擇，並點擊 Finish即可。要在以後再添加它們，您可以選擇 Help > Software Updates > Pending Changes... 來再次打開那個對話框。
已經被接受的變更在以後還可以禁用。打開 Install/Update 透視圖，在 Install Configuration 視圖中選中功能部件，然後在 Preview視圖中選擇 Disable 。禁用的功能部件還可以通過類似的步驟啟用。在 Install Configuration視圖中點擊 Show Disabled Features圖標可以顯示被禁用的功能部件。
功能部件在運行期標識組件
Eclipse 允許標識活動產品，也可以選擇標識運行期配置中的每一個功能部件。功能部件不是必須要標識出來，您可以不標識您所有的功能部件，但是您應該至少標識一個。
標識定義――插件的工作
添加標識的關鍵問題是要明白把標識的定義在哪裡。您定義標識的是功能部件，但是標識的內容是來自於插件。或者插件與功能部件的 id 相同（默認的情形），或者插件在功能部件的定義中被明確標識（這是 Eclipse 2.1.1 的新增功能）。在 Eclipse 2.1 中，一個功能部件定義可以通過在 feature.xml 文件中指定屬性 plugin=… 來定義其他插件。
插件包含了用於定義和提供標識內容的文件。
標識內容概要介紹
about.ini 控制文件定義了產品級和功能部件級的標識。產品標識必須正確包含以下兩方面內容：
功能部件必須被定義為一個可能的主要功能部件，即在 feature.xml 定義文件中要包含 primary="true"。
功能部件必須被標識為活動的主要功能部件，在產品中通常是在 \eclipse 目錄下的 install.ini 文件中的條目來設置。主要功能部件也可以在運行期通過使用 -feature featureId啟動參數來定義。
理解功能部件標識的最簡單的辦法是去查看在 about.ini 控制文件中定義了哪些元素，以及它們在一個被標識的產品或功能部件中如何起作用。
圖 2. 在 Eclipse 透視圖中可用的標識內容
以下幾條僅用於產品標識：
windowImage
appName
aboutImage
其余條目在產品及功能部件標識過程中使用。
以百分號(%)開頭的值在 about.properties 文件中解析。當一個功能部件是主要功能部件時，用 abouText 關鍵字定義的文本會在 About product 對話框中顯示。當用戶點擊 Feature Details 按鈕時，隨後彈出的 About Features 對話框中也會顯示這些本文內容。
功能部件被加入到運行期配置時，會打開 welcomePage 條目指定的歡迎頁面，其後還可以通過選擇 Eclipse 菜單選項 Help > Welcome... 打開的 Welcome 選擇對話框打開這個歡迎頁面。
構建一個可行的有標識的功能部件的最快速方法是克隆一個在 Eclipse 本身中可以找到的一個現有的功能部件。具有 org.eclipse.platform id 的功能部件和插件會提供功能部件標識和插件標識。在The Java Developer's Guide to Eclipse一書第34章練習7中有一個步驟詳盡的指導說明。
在 Eclipse.org 的更新管理器子工程的開發資源中，您可以找到另外一些關於標識的詳細說明。
使用 PDE 構建功能部件的策略
在The Java Developer's Guide to Eclipse一書中關於功能部件開發的章節和 Eclipse.org 的文章 "PDE 生成插件"中都對構建功能部件的過程進行了介紹，但是也還有一些其他的途徑。當您理解了如何使用 PDE 來構建功能部件和相關聯的插件之後，您可以讓這些步驟自動完成。
由 PDE 實現的 Ant 目標
讓我們從對 PDE 所提供功能概要介紹開始講起。PDE 將為一個 plugin.xml 或 feature.xml 文件生成 build.xml 文件。Build.xml是一個 Ant 腳本，可以完成運行期平台的功能部件和插件所需要的不同任務。PDE 構建過程允許您生成下列構建目標中的一個或多個。
重要的功能部件構建目標：
build.jars為每一個引用到的插件調用 build.xml 文件中的 build.jars 任務。
build.update.jar 為每一個引用到的插件調用 build.xml 文件中的 build.update.jars 任務。同時會為功能部件創建一個 Update JAR。這是 Ant 腳本的默認目標。
build.sources為每一個引用到的插件調用 build.xml 文件中的 build.source 任務。
zip.distribution創建一個包含功能部件和引用到的插件所需要的所有文件的壓縮文件。
refresh使 Eclipse 刷新功能部件工程及任何引用到的插件的工程。
重要的插件構建目標：
build.jars 為插件定義的每一個運行期 JAR 調用 build.xml 文件中的許多目標。被調用的目標的名字與運行期 JAR 文件的名字相同。這些目標編譯 Java 代碼並創建 JAR 文件，包含任何在源文件目錄下的資源。
build.update.jar 將所有運行期插件目錄下所有需要的文件壓縮打包為一個名字為 plugin.id_version.jar 的文件，在這裡 plugin.id 和 version 來自於 plugin.xml 文件。這是 Ant 腳本的默認目標。
build.sources基於給定的運行期 JAR 文件所定義的源文件目錄，創建 Java 源文件的壓縮包。
zip.plugin創建一個包含有插件所需要的所有內容的壓縮包。
refresh使 Eclipse 刷新插件工程。
注意：在功能部件和插件的Ant 處理過程中，更新 JAR 或生成壓縮包的處理過程中打包的文件，是運行期環境所需要的那些文件。這些內容在功能部件或插件的 build.properties 文件和在 plugin.xml 中定義的每一個插件的運行期 JAR 文件中，通過 bin.includes 或者 bin.excludes 條目來描述。
為了構建一個插件，您可能會指定 clean，build.sources，build.jars，zip.plugin，refresh。為了構建一個功能部件，您可能會指定 clean，build.sources，build.jars，zip.distribution，refresh。您或許會想要在開始時使用 clean 來強制重新生成所有結果，經常會有這種情況。盡管 Ant 處理過程將基於輸入的變化重新執行所需要的步驟，但是有一些變化不會觸發所有需要的處理過程。測試結果表明如果您改變了一個 Java 源文件，相應的源文件壓縮包將會更新，但是類不會被重新編譯，運行期 JAR 也不會被更新。所以安全起見，建議您先將輸出結果清空，以保證您在重新構建後所使用的是對應於當前源文件的運行期版本。
討論方案
為了進行討論，我們先描述一下只有一個功能部件和插件時在運行期配置中需要的內容。
組件結構示例
組件類型 文件 功能部件 feature.xml feature_image.jpg /license/license.html /license/license.pdf /plan/project-plan.doc 插件 plugin.xml /images/action.gif /images/editor.gif /src/co/pkg/id/action.java /src/co/pkg/id/editor.java /design-docs/plug-in.doc /design-docs/editor.doc 正如您所看到的文件名，雖然這些文件大部分屬於運行期環境，還是有一些文件不是您想要與其他人共享的（例如，您的設計文檔）。
包含策略――指出所需要的部分
至少到剛開始時，最簡單的方法是，在構建過程中將您要打包的部分作為在運行期配置中功能部件或插件的一部分而列出來。相應的 build.properties 文件分別如下所示：
build.properties 內容
組件
build.properties 文件內容
功能部件
bin.includes = feature.xml,\
license/
插件
source.runtime.jar = src/
bin.includes = plugin.xml,\
images/
排斥策略――指定不需要的或私有的部分
另一種方法是把您不想打包的部分在構建過程中作為功能部件或插件的一部分列出來。這不僅要包括您不想共享的文件，還要包括構建過程中創建的文件和目錄（有一些是臨時的）。這種方法用到的 build.properties 文件如下：
build.properties 內容
組件
build.properties 文件內容
功能部件
bin.excludes = temp.folder/,\
com.ibm.master.lab.core_1.0.0.bin.dist.zip,\
.classpath,\
.project,\
build.xml,\
build.properties
插件
bin.excludes = temp.folder/,\
bin/,\
.classpath,\
.project,\
build.xml,\
build.properties,\
makesrczip.xml,\
src/
如果給定功能部件或插件的 id 值為 com.your.feature.id 或者 com.your.plugin.id，那麼您在使用排斥策略的時候還需要在文件中包括以下條目：
com.your.feature.id_1.0.0.bin.dist.zip,\
com.your.feature.id_1.0.0.jar,\
com.your.plugin.id_1.0.0.jar,\
zip 條目將使生成的組件壓縮包不被 update JAR 或者組件壓縮包自己所包含。JAR 條目將使生成的功能部件或插件的 update JAR 不被組件壓縮包或者 update JAR 自己所包含。
當您的組件壓縮包或者 update JAR 看起來比它應該的大小要大，或者在每次您進行編譯時包的大小呈跳躍式增長，說明您應該執行以上步驟了。您需要在適當的功能部件或者插件的 build.properties 文件中加入以上條目來解決這個問題。
對文件或者結構變化的響應
除了以上提到的之外，當一個新的文件或目錄添加到功能部件或者插件時，還有必需的響應需要考慮。我們的意思是您得讓您的功能部件和插件能應付可能的改變，也就是說它們分別需要一個 feature.properties 文件和一個 plugin.properties 文件。當您用包含策略時，您需要給 .properties 文件添加一個適當的屬性，如果是使用排斥策略的話就不用這樣做了。
不論哪種方法，如果您把一個文件添加到一個目錄，那麼不需要做任何其他的改動。對於新添加的文件，如果使用的是包含策略，它會被發送處理，如果使用的是排斥策略，它將不會被發送處理。這實際上是您可能應該要考慮使用不同的目錄來存放不同的文件的原因。例如，您的插件所用到的所有圖片所在的目錄應該被包含在內，而一個開發過程中存放插件的設計討論或文檔的目錄則不然。
最壞的情形是當您忘記對 build.properties 進行更新時：會發生運行期失敗或生成內容存在差錯的產品。如果您使用包含策略，新加入的文件或目錄在打包後是不可用的，這有可能會導致您的插件不能用或者顯示出 Eclipse 默認的圖標（紅盒子）。如果是使用排斥策略添加新文件或目錄，這些文件或目錄的內容在打包過程中會被包含進來。根據您的風格選擇適當的方法，從而把您忘記執行更新時的風險降到最低。這將取決於您所面臨的主要問題：是功能部件或插件不能運行，還是其他人本不應該看到運行期目錄下的文件。
組織功能部件
當您在開發您的工具時，您是否考慮到了需要多少個插件？答案是至少三個：一個是您的模型，也就是非 UI 的核心部分，一個是您的 UI 內容，還有一個或多個是用於提供幫助內容。如果您注意過，您會發現這是 Eclipse 本身的基本模式（jdt.core, jdt.ui, jdt.doc; debug.core, debug.ui;等等）。
這樣劃分的原因之一是，相對於不用於 UI 的插件來說，用於 UI 的插件在運行期需要不同的 Eclipse 組件的支持（org.eclipse.ui）。
包含其他功能部件
功能部件如果沒有被其他功能部件包含，那麼在 Eclipse 配置中都會被配置為根功能部件。默認情況下，根功能部件可以由用戶在 Install/Update 透視圖中禁用或啟用，並且可以在 feature.xml 文件中確定一個更新 URL。當包含一個功能部件時，只有在根功能部件中的更新 URL 會被處理，否則只能通過 search-location 定義特別許可才可以。
通過包含功能部件，您可以管理包的組織結構。您可能會有多個功能部件，但只有一個做過標識，其余的或者是用來構成結構，或者是用來管理組件。請記住是根功能部件來定義更新的站點，盡管這個角色可以由功能部件委派給它所包含的功能部件，通過設置 search-location 屬性值為 selfboth。
如果您正在構建一個基於 Eclipse 的產品，您可能希望您的一個功能部件來包含 Eclipse 功能部件樹。對於標識這個產品來說這並不需要，但是您可以指定另外的更新站點（Eclipse 自己用的是 http://update.eclipse.org/updates），或者根本不指定更新站點，禁用基於 Web 的更新。
可選功能部件的角色
當將一個功能部件包含到另一個功能部件時，您可以選擇是否把它設置為可選的。主要原因是創建這樣的結構可以讓用戶根據他自己的需要來禁用您提供的組件的一部分。
當新的功能部件包含有可選功能部件，但那些可選功能部件並不存在時，Eclipse 的配置邏輯不允許添加這個新的功能部件。也就是說，如果適當的先決條件成立，可以使用可選功能部件來創建層結構。不過需要將這些層存貯在不同的目錄樹下，並且每層使用單獨的鏈接文件。您可以添加到 Eclipse 配置以增加其功能的鏈接文件的沒有數目上的限制。
讓 Eclipse (或者任何基於 Eclipse 的產品)以您的方式工作
現在向您講明了兩點：指定的主要功能部件控制整個產品的標識和默認屬性，Eclipse 可以在安裝配置目錄下或者任何一個鏈接的 Eclipse 目錄結構下找到組件。這意味著您可以改變 Eclipse (存在相關風險，不過僅僅意味著您修改時需要小心！)。這些改變可以幫助您管理基於 Eclipse 的安裝配置，並使之支持您個人所喜好的屬性規則。
使用鏈接文件來管理 Eclipse 安裝配置
您可能會希望能對環境進行更多的管理，而不是毫無選擇地將所有的插件（我希望是引用到的功能部件）全部安裝到您的 Eclipse 目錄樹下。如果您需要更新 Eclipse，實際上您並不想要另外再裝一個新的 Eclipse 或者在列表中去查找您所想要的功能部件和插件。
下面是一種借助鏈接文件來組織您的 Eclipse 或者基於 Eclipse 的產品和構件的方法：
保持 Eclipse 或者基於 Eclipse 的產品是干淨的。也就是說，不要把您的任何功能部件或者插件添加到 eclipse\features 和 eclipse\plugins 目錄下。
在已有的 eclipse 目錄下創建一個 eclipse\links 目錄和一個 eclipse\links-out 目錄。如果您用的是基於 Eclipse 的產品，那麼可能已經存在 eclipse\links-out 目錄。這個目錄並不特殊，只是一個用來方便存放不用的鏈接文件的地方。
為您要添加到您的配置中的功能部件和插件創建一個或多個 add-ons 的目錄。在這些目錄下，創建一個 eclipse\features 和一個 eclipse\plugins 目錄結構。
為每一個 add-ons 目錄在 eclipse\links-out 目錄下創建一個鏈接文件。將那些您當前要添加到您的活動配置中去的鏈接文件拷貝到 eclipse\links 目錄。
例如，假定您將 Eclipse 解壓縮到一個名為 Eclipse-2.1.1 的目錄下，然後創建一個名為 CoolTools 的 add-ons 目錄，也放在 Eclipse-2.1.1 目錄下。在 CoolTools 目錄下，您可以有多個目錄，每個目錄用於一個或一族您要添加到 Eclipse 的工具。您的目錄結構可能會如圖3所示。
圖 3. Eclipse 的鏈接文件目錄結構
EditorList.link 文件要包含下面其中一條（不能是全部）
path=D:/Eclipse-2.1.1/CoolTools/EditorList
path=D:\\Eclipse-2.1.1\\CoolTools\\EditorList
斜槓是一條（/）還是兩條（\\）取決於目錄結構。
確認條目不要以空格結尾，因為這樣 Eclipse 會忽略它――我第一次用鏈接文件時用了好幾個小時才弄明白這一點。
如果您使用一個新的工作區來啟動 Eclipse，所有 Eclipse 自帶的以及通過鏈接文件找到的功能部件和插件都是可用的。如果您要添加一個鏈接文件，並使用現有的工作區重新啟動 Eclipse，Configuration Changes 對話框就會彈出。如果您刪除了一個鏈接文件（很簡單，只是把它移到 \links-out 目錄下），配置的變化也會被 Eclipse 注意到，但您能看到的僅僅是 splash-flash。
實際上您不是必須將鏈接文件移入移出來控制配置，更好的辦法是用 Install/Update 透視圖來調整配置。當然，可以這樣做的前提是您的插件都屬於功能部件（看，這是另外一個需要功能部件的理由）。使用 Eclipse 進行配置的調整將以後面討論。
使用 Install/Update 透視圖來修改配置
根功能部件，以及任何定義為可選擇的功能部件，都可以在當前配置中禁用。被禁用後，功能部件仍然可以被平台認出；它們只是不再包含在當前的運行期配置中。
前面我們談及了將 Eclipse Examples 添加到活動配置中。添加後，我們可以使用 Install/Update 透視圖來禁用它。如果您正打開一個包含有 Eclipse Examples 的 Eclipse 配置的 Install/Update 透視圖，您看到的將如圖4 所示。
圖 4. 在 Install/Update 透視圖中的 Eclipse Examples 功能部件
在 Preview 視圖中點擊 Disable Now 按鈕，您就可以將 Eclipse Examples 功能部件從運行期配置中臨時移除。點擊後，Eclipse 將提示您重新啟動平台來使配置的修改生效。
Eclipse Examples 功能部件在當前配置中將不再可見（或者說不是活動的）。為了能再次看到這個功能部件並啟用之，您需要在 Install Configuration 視圖中點擊 Show Disabled Features開關按鈕（見圖5）。
圖 5. 在Install/Update 透視圖中禁用 Eclipse Examples 功能部件
由於 Eclipse Examples 功能部件是一個根功能部件，所以可以這樣做。如果您在 Eclipse SDK 中浏覽其他功能部件，您將發現它們在 Preview 視圖中沒有相應的 Disable Now按鈕，這是因為它們被定義為必需的。
如果您用的是 Eclipse SDK，您應該會有默認配置的平台、JDT 和 PDE。如果您正在做一些插件的開發，但是您不需要 PDE——或者在一些情況下，您不是總需要 JDT——您只要對 Eclipse 做一個小的修改就可以禁用這些功能部件。打開 org.eclipse.platform.sdk.win32 功能部件的 feature.xml 文件，將以下幾行修改為包含 optional="true" 屬性。
清單 1. 禁用 PDE 和 JDT
<includes id="org.eclipse.platform.win32" version="2.1.1" match="equivalent"/>
<includes id="org.eclipse.jdt" version="2.1.1" match="equivalent" optional="true"/>
<includes id="org.eclipse.pde" version="2.1.0" match="equivalent" optional="true"/>
<includes id="org.eclipse.platform.win32.source" version="2.1.1" match="equivalent"
optional="true"/>
<includes id="org.eclipse.jdt.source" version="2.1.1" match="equivalent" optional="true"/>
現在您可以在 Install Configuration 視圖中選擇這些功能部件並禁用它們。如果所有前面提到那些定義為可選擇的功能部件都被禁用，平台依然可以運行。並且，您隨時可以重新啟用它們。圖6 是 Install Configuration 視圖中顯示的被禁用的功能部件。
圖 6. 禁用 Eclipse 多個的功能部件
這些禁用/啟用的設置都是僅對於當前工作區有效。您可以有另外的活動工作區，其中包含有部分或全部在當前工作區中被禁用的功能部件。
這個簡單的例子說明了使用功能部件的優勢（它們可以被禁用）和使用鏈接文件來將所有可能的功能部件添加到您的配置的意義所在。在一個給定的工作區中將您所不需要的功能部件禁用，這樣就可以優化當前配置。
定義自己的全局屬性
Eclipse 是一個優秀的工具，但是同任何工具一樣，您得對它進行定制，它才能是完美的。工具提供了屬性頁面來讓您改變工具的行為或可視化顯示。最新統計，在 Eclipse 中有 62 個屬性頁面。幾乎每次您使用到一個新工具，您都會發現有些選項您想要修改。但是當您使用多個工作空間時，或者是在一個團隊的環境中工作，有一些選項需要與他人協調，這樣就出現了如何在跨工作空間以及與他人協調工作時對選項進行最佳管理的問題。
Eclipse 提供了導入/導出屬性的功能。在任何一個屬性對話框中，您都可以將屬性導出到一個 .epf 文件中。當使用其他工作區或與他人共享時，可以再次導入這個文件。您甚至可以將它添加到工程中與團隊成員共享，以便每個人都可以得到標准的屬性。
但是這樣做會變得單調而乏味，並且如果您忘記了就麻煩了。在使用 Eclipse 或任何基於 Eclipse 的產品時，您應該意識到還有另外一種方法可以定義全局屬性。您可以通過修改主要功能部件的 plugin_customization.ini 文件來定制屬性的默認值。
您可以在 eclipse 目錄下的 install.ini 文件中找到主要功能部件。例如，在標准的 Eclipse 解壓縮中的 install.ini 的內容如下：
清單 2. 標准的 Eclipse 解壓縮中的 install.ini 的內容
# install.ini
# java.io.Properties file (ISO 8859-1 with "\" escapes)
# This file does not need to be translated.
# Required property "feature.default.id" contains the id of the primary feature
# (the primary feature controls product branding, splash screens, and plug-in customization)
feature.default.id=org.eclipse.platform
# Required property "feature.default.application" contains id of the core
# application that gets control on startup. For products with a UI, this
# is always org.eclipse.ui.workbench; for "headless" products, this is product-specific.
feature.default.application=org.eclipse.ui.workbench
feature.default.id=… 指定了默認的主要功能部件。要注意的是，通過在啟動 Eclipse 時使用 -feature 選項，可以把其他功能部件聲明為是主要的。
同大部分功能部件控制和標識一樣，實際的工作都是在功能部件相關聯的插件中完成的。對於 Eclipse來說，這是一個 id 與功能部件相同的插件，org.eclipse.platform 插件。如果您仔細查看這個作為主要功能部件標識的插件，您將發現一個名為 plugin_customization.ini 的文件。這個文件的內容與導出屬性的文件類似。當 Eclipse 啟動時會讀取這個文件，並用來指定所有默認的屬性值，而不是去使用插件本身定義的那些值。這就使得產品，或者說是您，可以改變插件的行為。默認的 plugin_customization.ini 文件的內容只有一條：
清單 3. 默認的 plugin_customization.ini 文件
# plugin_customization.ini
# sets default values for plug-in-specific preferences
# keys are qualified by plug-in id
# e.g., com.example.acmeplugin/myproperty=myvalue
# java.io.Properties file (ISO 8859-1 with "\" escapes)
# "%key" are externalized strings defined in plugin_customization.properties
# This file does not need to be translated.
# Property "org.eclipse.ui/defaultPerspectiveId" controls the
# perspective that the workbench opens initially
org.eclipse.ui/defaultPerspectiveId=org.eclipse.ui.resourcePerspective
這一條目指定了打開新的工作區時以及當您關掉所有的透視圖後關閉 Eclipse 時打開的透視圖。如果您使用的基於 Eclipse 的產品，這個條目可能有所不同。
指定要包含的屬性的過程比較費事，但至少您應該做如下步驟：
啟動一個干淨的工作區。
修改您想要改變的一個屬性。
將屬性導出到一個 .epf 文件。
在導出的文件中找到新的健值，並確定它是否反映了您剛剛所做的改變。
將一個或多個鍵的條目拷貝到標識插件（使用 Eclipse 時這個插件是 org.eclipse.platform）的 plugin_customization.ini 文件中。
測試結果，或者保留新的鍵，或者再試一次。
注意：如果您不習慣於去更新產品的 plugin_customization.ini 文件，您可以在其他位置創建一個這個文件的拷貝，在啟動 Eclipse 或基於 Eclipse 的產品時使用參數來指定它。
eclipse -plugincustomization myCustomDefaults.ini
全局屬性示例
前面提到了一些相關技術的描述，並提出了對您可能希望包含到您定制的 plugin_customization.ini 文件中的一些值的建議，這裡給出了示例屬性重寫，作為對前面兩方面的內容的說明。
我們將把它們根據我定制的目的在邏輯上分為的幾部分來介紹。您可以下載完全的 插件 customization.ini 文件。
視圖欄默認是在底部，但我喜歡把它們放在頂部：
# View tabs at the bottom
org.eclipse.ui.workbench/VIEW_TAB_POSITION=128
新工作區打開時不打開歡迎頁面，並且在關閉工作台時不再提示：
# No welcome dialog at open and no confirm on close
org.eclipse.ui.workbench/WELCOME_DIALOG=false
org.eclipse.ui.workbench/EXIT_PROMPT_ON_CLOSE_LAST_WINDOW=false
在打開新工程向導所知的透視圖時，禁用提示或其他動作：
# Never change to perspective required by new project wizard (no prompt)
org.eclipse.ui.workbench/SWITCH_PERSPECTIVE_ON_PROJECT_CREATION=never
定義另外的默認文本字體：
# Default text font (leaks into Java editor)
# Note: you have to touch the font page and say OK/Apply (probable bug)
org.eclipse.ui.workbench/org.eclipse.jface.textfont=
1|Lucida Console|9|1|WINDOWS|1|-15|0|0|0|700|0|0|0|0|3|2|1|49|Lucida Console;
注意：字體屬性條目比較特殊，對它的修改不會立即生效。如果您訪問字體屬性頁，前面所定義的內容會顯示出來，不過得在您選擇了 OK 或者 Apply 之後才會生效。我不能讓這個鍵保存下來用於 Java 文本字體。
預定義附加的 Java 編輯器任務標簽：
# Add to the default JDT task tags (TODO should probably be left)
org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.taskTags=TODO,Edu-Sol
將對 Package Explorer 的雙擊默認設置為 Go Into 動作：
# Package Explorer GoInto on Double click
org.eclipse.jdt.ui/packageview.doubleclick=packageview.gointo
有一些沒有定義屬性頁面的選項也是可以定制的。在完成對 UI 的標准設置後導出的 .epf 文件中，我發現有一些 JDT 的選項值是作為屬性來保存的。
這個屬性鍵是用於告知 JDT UI 它要讀取屬性並用來改變默認的 UI 行為：
# Tells JDT it does have some prefs to use (forces a read of these values)
org.eclipse.jdt.ui/CustomFiltersActionGroup.org.eclipse.jdt.ui.PackageExplorer.
TAG_DUMMY_TO_TEST_EXISTENCE=storedViewPreferences
注意：如果沒有上面的這個屬性鍵，接下來的兩組設置將被忽略。
活動 Package Explorer 過濾器以屬性值的形式保存：
# Package Explorer filter - standard JDT defaults + library filter
org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer.LibraryFilter=true
org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer_patternFilterId_.*=true
org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer.PackageDeclarationFilter=true
org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer_patternFilterId_*$*.class=true
org.eclipse.jdt.ui/org.eclipse.jdt.internal.ui.PackageExplorer.EmptyInnerPackageFilter=true
Outline 視圖有一個顯示選項，可以在活動的 JDT Java 編輯器中顯示內容時減小樹的深度。這個圖標有一個懸浮幫助 Go Into Top Level Type，由下面這個屬性項來控制： # Outline view GoInto Toggle when using JDT editor
org.eclipse.jdt.ui/GoIntoTopLevelTypeAction.isChecked=true
您可能會想要嘗試為更多的屬性指定新的默認值，使用前面描述的方法然後核對一下結果即可。您或許會希望在一個臨時的工作區中做這些事情，達到修改的目的後，您可以按此去修改活動的主要功能部件的 plugin_customization.ini 文件（不要告訴任何人是我教您這樣做的！）。並且要注意的是，您可能會發現其他一些鍵被忽略了，這種情況我也曾遇到過，因為字體是用於 JDT 的，因此這一條目加入到 plugin_customization.ini 文件後，在屬性頁中根本就不會體現出這種變化。
結束語
功能部件是 Eclipse 的幕後英雄－－它們很重要，因為它們是 Eclipse 配置管理的組成部分，支持產品標識，並且它們是在 Eclipse 平台上構建定制解決方案的產品的一部分。使用功能部件您可以：
當您使用基於 Eclipse 的產品進行工作時，您可以根據功能部件標識鑒別出是誰提供了哪些不同的可用功能
對產品的標識可以幫助進一步定制 Eclipse
在插件開發環境中自動完成任務
通過禁用/啟用根功能部件，或者使用 Install/Update 透視圖來禁用/啟用定義為可選的被包含的功能部件，您可以動態地改變給定工作區的配置
所以，使用功能部件吧，它可以幫助您自動完成構建插件的一些步驟，使用文中提到的自定義 install/link 文件組織方法，可以使您的 Eclipse 環境更加好用。
