邏輯模型整合的儲存庫導覽圖

如果要提供完整的邏輯模型支援,儲存庫提供者可以執行下列步驟:

  1. 提供配合 ResourceMapping 而改寫的元素之適當儲存庫作業。
  2. 利用 ISynchronizationScope 和支援的 API,確保在資源對映上執行的作業包含所有適當的模型元素和資源。
  3. 讓模型提供者透過 IMergeContext 介面和支援的 API 來參與無監視器型合併。
  4. 讓模型提供者在合併所涉及的模型上使用 teamContentProviders 來參與合併的預覽。提供的 ModelSynchronizeParticipant 類別用來協助管理模型內容、合併環境定義和比較架構之間的關係。
  5. 利用 IFileHistoryProvider API 來提供存取工作區檔案的能力
  6. 利用 org.eclipse.core.filesystem 外掛程式中的「Eclipse 檔案系統 API」來提供存取遠端配置的能力,以及利用 ProjectSetCapability 將這個鏈結到工作區專案
  7. 提供工作區 Subscriber 來搭配 SynchronizationStateTester API,以支援邏輯模型元素裝飾。

下列各節會分別詳細說明這幾點。 org.eclipse.team.examples.filesystem 外掛程式含有一個範例,可以說明若干這些要點。 您可以從 CVS 儲存庫移出專案,用它來作為閱讀這份教學指導時的參考資料。免責聲明:這個範例外掛程式中的程式碼可能會在一段時間之後有所改變。 如果要取得符合這個範例所用內容的副本,您可以利用 3.2 版標示(很可能是 R3_2)或 2006 年 6 月 28 日的日期標示來移出專案。

將動作提供給資源對映

基本資源對映 API

資源對映 API 由下列類別組成:

在資源對映中,有兩類應該有用的外掛程式。 一種是提供模型的外掛程式,且所提供的模型由工作區資源組成或持續保存在工作區資源中,一種是想要在資源上執行作業的外掛程式。 模型導覽圖討論前者,下一節討論後者。

資源對映和物件構成要素

向適應性延伸點提供延伸規格的外掛程式必須進行兩項變更,以便支援新的 ResourceMapping API:

  1. 在外掛程式的 plugin.xml 檔中,更新 popupMenus 延伸點的任何 objectContributions,將目標鎖定 ResourceMapping,而不是 IResource(針對適合者而言)。
  2. 將外掛程式的動作更新為處理 ResourceMapping,而不是 IResource,且遵循遍訪所提供的深度限制。

將物件構成要素加到 IResource 的外掛程式,現在,如果這個動作能夠套用到多項資源,便可以改成將這些物件構成要素加到 ResourceMapping 中。 以下是將功能表動作提供給配合資源對映而改寫之物件的 XML 片段:

   <extension
       point="org.eclipse.ui.popupMenus">
      <objectContribution
            objectClass="org.eclipse.core.resources.mapping.ResourceMapping"
            adaptable="true"
            id="org.eclipse.team.ccvs.ui.ResourceMapperContributions">
         <enablement>
<adapt type="org.eclipse.core.resources.mapping.ResourceMapping">
<test
property="org.eclipse.core.resources.projectPersistentProperty"
args="org.eclipse.team.core.repository,org.eclipse.team.cvs.core.cvsnature" />
</adapt>
</enablement>
<action
label="%UpdateAction.label"
definitionId="org.eclipse.team.cvs.ui.update"
class="org.eclipse.team.internal.ccvs.ui.actions.UpdateAction"
tooltip="%UpdateAction.tooltip"
menubarPath="team.main/group2"
id="org.eclipse.team.cvs.ui.update">
</action>
...
</objectContribution>
</extension>

提供給 ResourceMapping 的構成要素會自動套用到配合 IResource 而改寫的物件。 這項轉換關聯由工作台來處理。 對於提供給資源對映之構成要素的過濾,是利用啟用表示式來進行的。 依專案持續性內容來過濾的表示式已新增好,可讓儲存庫提供者將它們的功能表顯示在對映至它們的儲存庫的專案上。

已提供給 ResourceMapping 類別的動作會得到含有一或多項 ResourceMappings 的選項。 這些動作負責將資源對映轉換成一組要處理的資源。 這可以藉由呼叫 getTraversals 取得對映遍訪來完成。 遍訪使遍訪的用戶端能夠根據所遍訪之資源的深度來最佳化它們的作業。 用戶端可以手動遍訪資源,也可以利用資源和深度來作為動作委派它工作之動作的輸入。 比方說,如果使用者在 Java 套件上執行 CVS 更新,且這個「Java 套件資源對映」對映至深度為 1 的資料夾,CVS 便會發出適當的指令("cvs update -l" - 提供給好奇的您), 這個指令會在套件所代表的資料夾上執行淺層更新。

雖然有可能直接從所選資源對映取得一組遍訪,但仍有模型關係(或儲存庫關係)可能需要將其他資源或模型元素併入作業中。 下一節說明如何確定所有必要的資源都已併入作業中

作業範圍

對於團隊作業而言,所選的對映必須轉換成要處理的一組對映。 這個程序包括咨詢所有模型提供者,以確保它們已併入符合其啟用規則之資源的作業中。 我們用來描述將處理的整組資源對映的詞彙,便是作業範圍。 以下是所提供這方面的 API:

SynchronizationScopeManager 類別的 initialize(IProgressMonitor) 方法會處理將輸入的資源對映集轉換成需要處理之全套對映的整個程序,以及涵蓋這些對映的全套遍訪。 儲存庫提供者可以依下列方式來裁剪程序:

  1. 提供從資源對映取得資源遍訪時所用的 RemoteResourceMappingContext
  2. 置換 SynchronizationScopeManager 來依照需要裁剪範圍管理程序。

下兩節詳細說明這幾點。

遠端資源對映環境定義

如果要保證所有必要的資源都併入團隊作業,模型提供者可能必須有能力瀏覽儲存庫中一或多項資源的狀態。 有些模型可能沒有這種需求。 比方說,Java 套件便是被造訪到某個深度的儲存檔案,不論模型的遠端狀態為何,都是如此。 在這個情況下,儲存庫提供者可以輕易判斷在確定時應該併入送出刪除,在更新時應該併入送入新增。 不過,構成某些邏輯模型的資源可能會隨著時間而改變。 例如,構成模型元素的資源可能會相依於 Manifest 檔(或其他類似機制)的內容。 為了使資源對映傳回適當的遍訪,它必須存取 Manifest 檔的遠端內容(如果不同於本端內容的話),以便瞭解是否需要併入其他資源。 這些其他資源不一定會在工作區中,但儲存庫提供者會知道在執行所選取動作時,如何確定它們在工作區中。

如果要支援這些比較複雜的模型,您可以將 RemoteResourceMappingContext 傳給 ResourceMapping#getTraversals 方法。 當提供環境定義時,對映可以利用它來確定遍訪併入了所有必要的資源。 如果未提供環境定義,對映可能假設只有本端狀態有用。

遠端資源對映環境定義提供了三項基本查詢:

上述第一個問題的回答會隨著所執行的作業類型而不同。 一般而言,更新和合併是三向,比較和取代作業(至少 CVS 是如此)是雙向。

「Eclipse 團隊 API」包含一個 Subscriber 類別,它定義了提供本端工作區和遠端伺服器間之同步化狀態的 API。 所提供的 SubscriberResourceMappingContext 利用 Subscriber 來存取必要的遠端狀態。 有 Subscriber 的用戶端不需要執行任何其他作業來取得資源對映環境定義。

繼承 SynchronizationScopeManager

您可以繼承 SynchronizationScopeManager 類別來裁剪範圍的產生和管理程序。 繼承這個範圍管理者的主要原因有兩個:

  1. 儲存庫提供者因為某個儲存庫層次關係而必須併入其他資源(如變更集)。 您可以置換 adjustInputTraversals(ResourceTraversal[]) 方法來完成這一點。
  2. 同步化的生命週期(如「同步化」視圖和對話框)比較長,必須有能力反應範圍的改變。 ISynchronizationScopeParticipant 介面定義模型提供者可用來參與範圍管理程序的 API。 SubscriberScopeManager 類別是使參與者包含在範圍管理程序中之 SynchronizationScopeManager 的子類別,以 Subscriber 為基礎。 工作組便是為何需要這類程序的範例。 如果工作組是範圍中的資源對映之一,當資源加到工作組中,範圍所涵蓋的這組遍訪也會增加。

基於模型的合併

合併是需要模型參與的主要儲存庫作業類型。 在許多情況下,模型只需要在檔案層次參與。 因此,便引進了 IStorageMerger API,讓模型提供者能夠提供應該用來合併特定延伸規格或內容類型的檔案之合併程式。 不過,在某些情況下,模型可能需要其他環境定義,才能適當參與合併。 因此,我們引進了 IResourceMappingMergerIMergeContext API。

關聯於儲存庫提供者的動作仍會觸發合併作業。 不過,使用者要求合併類型的作業之後,儲存庫提供者便必須使合併程序包含模型提供者,以確保合併不會以任何方式毀損模型。

儲存庫提供者 API 有兩個與基於模型的合併支援相關的主要片段。

  1. 說明合併所含資源之同步化狀態的 API。
  2. 可讓模型提供者合併模型元素的 API。
下列各節說明這兩個片段。

同步化狀態說明的 API

將涉及之資源的同步化狀態通知模型提供者時所用的 API,是基於模型之合併的一個重要方面。 下列介面用來說明同步化狀態:

對於所有這些介面,也都提供了抽象類別,慣例是類別名稱與介面名稱相符,但移除前面的 "I"。 儲存庫提供者必須置換的唯一類別是 ResourceDiff 類別,以便提供適當的前置和後置檔案修訂。

模型合併的 API

IMergeContext 介面利用其他支援合併的方法來繼承同步化環境定義。下列情況有回呼方法:

提供的抽象 MergeContext 類別含有許多合併行為的預設實作,另外,它也利用 IStorageMerger 來執行三向合併。 另外,也提供了 SubscriberMergeContext 類別,用來處理合併環境定義的相關同步化狀態說明的移入和維護。

提供的作業類別 ModelMergeOperation 利用 IResourceMappingMerger API 來執行基於模型的合併作業。 子類別必須置換 initializeContext(IProgressMonitor) 方法,以便傳回合併環境定義。 作業利用這個環境定義來嘗試基於模型的無監視器型合併。 如果衝突存在,合併的預覽會留給子類別。 如我們在下一節所見,存在著一個 ModelParticipantMergeOperation,它利用 ModelSynchronizeParticipant 來提供預覽功能。

團隊檢視器中的模型內容

團隊作業中之邏輯模型的顯示支援是利用 Eclipse 3.2 引進的「共用導覽器」架構來提供的。 邏輯模型可以利用 org.eclipse.team.ui.teamContentProvider 延伸點,將內容延伸規格關聯於模型提供者。 團隊提供者利用 ITeamContentProviderManager 來存取這些內容提供者。

以下是團隊提供者可能會想顯示邏輯模型的情況:

ModelSynchronizeParticipant 提供了在「同步化」視圖中的整合,以及能夠顯示 iSynchronizePages 的任何儲存檔案。 參與者利用預先存在的同步化參與者功能和「共用導覽器」功能,讓團隊提供者和模型能夠裁剪工具列、快速功能表和合併預覽的其他方面。 ModelSynchronizeParticipant 提供下列項目:

以下是特定團隊提供者之模型同步化參與者的裁剪步驟核對清單:

下列 XML 片段說明如何登錄 CVS 參與者類別,以及如何定義它的檢視器。

   <extension point="org.eclipse.team.ui.synchronizeParticipants">
       <participant
            name="CVS"
            icon="$nl$/icons/full/eview16/cvs_persp.gif"
            class="org.eclipse.team.internal.ccvs.ui.mappings.WorkspaceModelParticipant"
            id="org.eclipse.team.cvs.ui.workspace-participant">
      </participant>
   </extension>
   
   <extension point="org.eclipse.ui.navigator.viewer">
       <viewer viewerId="org.eclipse.team.cvs.ui.workspaceSynchronization">
           <popupMenu
                allowsPlatformContributions="false"
                id="org.eclipse.team.cvs.ui.workspaceSynchronizationMenu">
             <insertionPoint name="file"/>
             <insertionPoint name="edit" separator="true"/>
             <insertionPoint name="synchronize"/>
             <insertionPoint name="navigate" separator="true"/>
             <insertionPoint name="update" separator="true"/>
             <insertionPoint name="commit" separator="false"/>
             <insertionPoint name="overrideActions" separator="true"/>
             <insertionPoint name="otherActions1" separator="true"/>
             <insertionPoint name="otherActions2" separator="true"/>
             <insertionPoint name="sort" separator="true"/>
             <insertionPoint name="additions" separator="true"/>
             <insertionPoint name="properties" separator="true"/>
          </popupMenu>
       </viewer>
   </extension>

檔案歷程

已新增檔案歷程 API,讓模型能夠存取檔案的歷程。 檔案歷程 API 由下列介面組成:

隨著這個 API,也新增了一個一般的檔案「歷程」視圖。 這可讓「團隊提供者」將它們的檔案/資源歷程顯示在共用視圖中,也讓模型顯示未直接對映至檔案之元素的模型元素歷程。 「歷程」視圖是一個頁面型的視圖,它會利用下列方式來取得所選元素的頁面:

專案集功能

ProjectSetCapability 中,加入了若干方法來支援參照字串(用來識別專案和遠端內容之間的對映)與 URI(用來識別 org.eclipse.core.filesystem.filesystems 延伸點所登錄的檔案系統架構)之間的轉換。 「團隊提供者」可以選擇性地提供這方面的支援,讓邏輯模型能夠執行遠端瀏覽和專案載入。

裝飾模型元素

「團隊提供者」可以依照將提供物件轉換成適用於資源對映的相同方式,將它們的小型裝飾元轉換成適用於資源對映,以裝飾模型元素。 不過,邏輯模型元素裝飾有一個方面有問題。 如果模型元素與資源沒有 1:1 的對映,當基礎資源變更時,模型元素可能不會收到標籤更新。

為了處理這個問題,引進了 ITeamStateProvider,使模型提供者能夠存取可能會影響到團隊裝飾的狀態變更。 另外,模型視圖也可以利用 SynchronizationStateTester 來判斷何時需要更新邏輯模型元素的標籤。 這個 API 依賴 ITeamStateProvider 介面來判斷資源團隊狀態的變更時間,它可以傳遞給團隊裝飾元,而成為 IDecorationContext 的一部分。