Orientační plán úložiště pro integraci logického modelu

Pro zajištění plné podpory logických modelů může poskytovatel úložiště provést následující kroky:

  1. Přidávat příslušné operace úložiště do prvků, které se přizpůsobují ResourceMapping.
  2. Zajistit, aby operace prováděné na mapování prostředků zahrnovaly všechny prvky a prostředky modelů použitím ISynchronizationScope a podpůrného rozhraní API.
  3. Umožnit poskytovatelům modelů podílet se na slučování bez hlavičky prostřednictvím rozhraní IMergeContext a podpůrného rozhraní API.
  4. Umožnit poskytovatelům modelů podílet se na náhledech slučování použitím teamContentProviders pro modely zahrnuté ve sloučení. Pro usnadnění správy vztahu mezi obsahem modelu, kontextem sloučení a rámcem porovnání je poskytnuta třída ModelSynchronizeParticipant.
  5. Poskytnout přístup k historii souborů pracovní plochy prostřednictvím rozhraní API IFileHistoryProvider
  6. Poskytnout přístup ke vzdáleným konfiguracím pomocí rozhraní Eclipse File System API v modulu plug-in org.eclipse.core.filesystem a propojit na projekty pracovního prostoru prostřednictvím ProjectSetCapability
  7. Podporovat zdobení prvku logického modelu poskytnutím Odběratele pracovního prostoru pro použití s rozhraním API SynchronizationStateTester.

Každý z těchto bodů je podrobněji popsán v následujících oddílech. Modul plug-in org.eclipse.team.examples.filesystem obsahuje příklad, který ilustruje několik těchto bodů. Při čtení tohoto návodu můžete přezkoušet projekt z úložiště CVS a použít jej jako odkaz. Bez záruky: Zdrojový kód v ukázkových modulech plug-in se může časem měnit. Chcete-li získat kód reflektující vše, co je použito v tomto příkladu, můžete si zapůjčit projekt za použití značky verze 3.2 (nejpravděpodobněji R3_2) nebo značky data 28. června 2006.

Přidávání akcí do mapování prostředků

Základní rozhraní API mapování prostředků

Rozhraní API mapování prostředků se skládá z následujících tříd:

Existují dva typy modulů plug-in, které by měly být středem zájmu v mapování prostředků. Moduly poskytující model, který se skládá z nebo je obsažen v prostředcích v pracovním prostoru a moduly, které provádějí operace na prostředcích. První případ je obsažen v orientačním plánu modelu a druhý případ je obsažen v následujícím oddílu.

Mapování prostředků a příspěvky objektů

Moduly plug-in, které přidávají rozšíření do adaptovatelných bodů rozšíření budou muset podstoupit dvě změny, aby mohly podporovat nová rozhraní API ResourceMapping:

  1. Aktualizovat objectContributions bodu rozšíření popupMenus v souboru plugin.xml, aby směřovaly na ResourceMapping namísto IResource (pro ty, kterých se to týká).
  2. Aktualizovat akce pro práci na ResourceMapping namísto IResource a respektovat omezení hloubky obsažená v průchodech.

Moduly plug-in, které přidávají příspěvky objektů do IResource je mohou namísto toho nyní přidávat do ResourceMapping, pokud se akce použije na více prostředků. Následuje úsek kódu XML, který přidává akci nabídky do objektů, které se adaptují na mapování prostředků:

      <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>

Příspěvky do ResourceMapping se automaticky použijí na objekty, které se adaptují na IResource. Tato tranzitivní asociace je obsluhována pracovní plochou. Filtrování příspěvků na mapování prostředků lze provádět pomocí výrazů zpřístupnění. Výraz pro filtrování podle trvalé vlastnosti projektu byl přidán s cílem umožnit poskytovatelům úložišť, aby se jejich nabídky zobrazovaly v projektech, které jsou mapovány na jejich úložiště.

Akce přidané do třídy ResourceMapping dostanou výběr obsahující jedno nebo více ResourceMappings. Poté už je záležitostí akcí, aby převedly mapování prostředku do souboru prostředků, na kterých bude provozováno. Toho lze dosáhnout voláním getTraversals pro získání průchodů mapování. Průchody umožňují svým klientům optimalizovat jejich operace v závislosti na hloubce převáděných prostředků. Klient může převádět prostředky ručně nebo může použít prostředek a hloubku jako vstup do operace, která je akcí pověřena k provedení práce. Pokud například uživatel provádí aktualizaci CVS na balíčku java a mapování prostředku balíčku java provádí mapování na složku s hloubkou jedna, CVS vydá odpovídající příkaz ("cvs update -l" pro ty, které to zajímá), který provede mělkou aktualizaci ve složce, kterou balíček reprezentuje.

Přestože je možné získat soubor průchodů přímo z vybraného mapování prostředku, existují vztahy modelů (nebo vztahy úložišť), které mohou vyžadovat zahrnutí dalších prostředků nebo prvků modelu do operace. Následující oddíl popisuje, co je třeba udělat, aby byly všechny nezbytné prostředky zahrnuty v operaci.

Rozsah operace

Pro týmové operace musí být vybraná mapování převedena do souboru mapování, na kterých budou operace prováděny. Tento proces zahrnuje konzultace se všemi poskytovateli modelů, aby byli zahrnuti do operací na prostředcích, které odpovídají jejich pravidlům zpřístupnění. Úplný soubor mapování prostředků, na kterých budou operace prováděny označujeme jako rozsah operace. K tomu jsou poskytována následující rozhraní API:

Metoda initialize(IProgressMonitor) třídy SynchronizationScopeManager obsluhuje celý proces převodu množiny vstupů mapování prostředků na úplný soubor mapování, na kterých budou prováděny operace, stejně jako úplný soubor průchodů pokrývajících tato mapování. Poskytovatel úložiště může proces přizpůsobit prostřednictvím:

  1. Poskytnutí RemoteResourceMappingContext pro použití při získávání průchodů prostředků z mapování prostředků.
  2. Potlačení SynchronizationScopeManager pro přizpůsobení procesu správy rozsahu podle potřeby.

Následující dva oddíly popisují tyto body podrobněji.

Kontext pro mapování vzdálených prostředků

Ve snaze zajistit, že všechny nezbytné prostředky jsou zahrnuty v týmové operaci může poskytovatel modelu vyžadovat možnost nahlédnout na stav jednoho nebo více prostředků v úložišti. Pro některé modely to nemusí být potřeba. Například balíček java je kontejner navštěvovaný do hloubky jedna bez ohledu na vzdálený stav modelu. Poskytovatel úložiště tak může jednoduše stanovit, že odchozí odstranění by měla být zahrnuta při potvrzení nebo že příchozí přidání by měla být zahrnuta při aktualizaci. Prostředky tvořící logické modely se ovšem mohou v čase měnit. Například prostředky tvořící prvek modelu mohou záviset na obsahu souboru s manifestem (nebo jiném podobném mechanizmu). Aby mohlo mapování prostředku vrátit správný průchod, musí mít přístup ke vzdálenému obsahu souboru s manifestem (liší se od lokálního obsahu), aby mohlo zjistit, zda se vyskytují další prostředky, které je třeba zahrnout. Tyto dodatečné prostředky nemusí v pracovním prostoru existovat, ale poskytovatel úložiště by měl vědět, jak zajistit, aby tam byly při provádění vybrané akce.

Pro podporu těchto komplexnějších modelů může být RemoteResourceMappingContext přenesen na metodu ResourceMapping#getTraversals. Při poskytnutí kontextu jej může mapování použít k tomu, aby všechny nezbytné prostředky byly zahrnuty v průchodu. Pokud není kontext poskytován, mapování může předpokládat, že je předmětem zájmu pouze lokální stav.

Kontext pro mapování vzdálených prostředků poskytuje tři základní dotazy:

Odpověď na první výše uvedenou otázku závisí na typu prováděné operace. Aktualizace a sloučení jsou obvykle trojsměrné, zatímco porovnání a operace nahrazení (alespoň pro CVS) jsou dvousměrné.

Týmové rozhraní API platformy Eclipse obsahuje třídu Odběratel, která definuje API pro poskytování stavu synchronizace mezi lokálním pracovním prostorem a vzdáleným serverem. SubscriberResourceMappingContext využívající třídy Odběratel je poskytován pro přístup k nezbytnému vzdálenému stavu. Klienti s třídou Odběratel již nemusí pro získání kontextu mapování prostředků nic dalšího dělat.

Vytvoření podtřídy z SynchronizationScopeManager

Ze třídy SynchronizationScopeManager lze vytvořit podtřídu za účelem přizpůsobení procesu vytváření a správy rozsahu. Dvěma hlavními důvody pro vytvoření podtřídy ze správce rozsahu jsou:

  1. Poskytovatel úložiště potřebuje zahrnout další prostředky v důsledku určitých vztahů úrovně úložiště (např. sada změn). Toho lze dosáhnout potlačením metody adjustInputTraversals(ResourceTraversal[]).
  2. Synchronizace má delší životní cyklus (např. pohled vs. dialogové okno Synchronizovat) a potřebuje potenciál pro reakci na změny v rozsahu. Rozhraní ISynchronizationScopeParticipant definuje API, pomocí kterého se mohou poskytovatelé modelů účastnit procesu správy rozsahu. Třída SubscriberScopeManager je podtřídou na bázi Odběratele třídy SynchronizationScopeManager, která zahrnuje účastníky procesu správy rozsahu. Tento typ procesu je potřebný například kvůli pracovním sadám. Pokud je pracovní sada jedním z mapování prostředků v rozsahu, soubor průchodů pokrytých rozsah se zvýší, pokud se do pracovní sady přidají prostředky.

Slučování na bázi modelů

Základním typem operace úložiště, která vyžaduje účast modelu je slučování. V mnoha případech je nutná účast modelů pouze na úrovni souboru. K tomu bylo zavedeno rozhraní API IStorageMerger, které umožňuje poskytovatelům modelů přidávat sloučení za účelem slučování souborů určitého typu rozšíření nebo obsahu. V některých případech mohou ovšem modely potřebovat další kontext pro odpovídající účast ve sloučení. K tomuto účelu byla zavedena rozhraní API IResourceMappingMerger a IMergeContext.

Operace sloučení jsou stále spouštěny akcemi asociovanými s poskytovatelem úložiště. Jakmile si ovšem uživatel vyžádá operaci typu sloučení, poskytovatel úložiště musí zahrnout poskytovatele modelů do procesu sloučení, aby sloučení model nějak nepoškodilo.

Existují dvě hlavní části rozhraní API poskytovatele úložiště související s podporou slučování na bázi modelů.

  1. API popisující stav synchronizace prostředků zahrnutých ve sloučení.
  2. API umožňující poskytovatelům modelů slučovat prvky modelů.
Následující oddíly popisují tyto dvě části.

API pro popis stavu synchronizace

Důležitým aspektem slučování na bázi modelů je rozhraní API používané pro komunikaci stavu synchronizace prostředků zahrnutých ve sloučení poskytovateli modelu. Pro popis stavu synchronizace se používají následující rozhraní:

Abstraktní třídy jsou poskytnuty pro všechna tato rozhraní s použitím konvence, že názvy tříd odpovídají názvům rozhraní s odstraněnou předponou "I". Jedinou třídou, kterou poskytovatelé úložišť musí potlačit je třída ResourceDiff, aby mohly být poskytnuty odpovídající revize souborů před a po.

API pro slučování modelů

Rozhraní IMergeContext rozšiřuje kontext synchronizace o další metody podporující slučování. Metody zpětného volání existují pro:

Je poskytnuta abstraktní třída MergeContext, která obsahuje výchozí implementace pro značnou část chování sloučení a která rovněž používá IStorageMerger k provádění trojsměrných sloučení. Rovněž je poskytnuta třída SubscriberMergeContext, která zpracovává naplnění a údržbu popisu stavu synchronizace asociovaného s kontextem sloučení.

Třída operace ModelMergeOperation využívající rozhraní API IResourceMappingMerger je poskytnuta pro provádění operace sloučení na bázi modelů. Podtřídy musí potlačit metodu initializeContext(IProgressMonitor) pro získání kontextu sloučení. Operace používá tento kontext ve snaze o sloučení na bázi modelů bez hlavičky. Při výskytu konfliktů je náhled sloučení ponechán na podtřídě. Jak uvidíme v následujícím oddílu, existuje ModelParticipantMergeOperation poskytující možnosti náhledu pomocí ModelSynchronizeParticipant.

Obsah modelu v týmových prohlížečích

Podpora zobrazení logických modelů v týmové operaci je poskytována pomocí rámce společného navigátoru Common Navigator, který byl zaveden v Eclipse 3.2. Logické modely mohou asociovat rozšíření obsahu s poskytovatelem modelu pomocí bodu rozšíření org.eclipse.team.ui.teamContentProvider. Týmoví poskytovatelé mají přístup k těmto poskytovatelům obsahu prostřednictvím ITeamContentProviderManager.

Existuje několik míst, kde mohou týmoví poskytovatelé chtít zobrazovat logické modely:

ModelSynchronizeParticipant poskytuje integraci do pohledu Synchronizace nebo do libovolného kontejneru, který může zobrazit iSynchronizePages. Účastník využívá jak již existujících schopností synchronizace, tak i schopností společného navigátoru Common Navigator k tomu, aby měli týmoví poskytovatelé a modely možnost přizpůsobit panel nástrojů, kontextovou nabídku a ostatní aspekty náhled sloučení. ModelSynchronizeParticipant poskytuje:

Následuje kontrolní seznam kroků pro přizpůsobení účastníka synchronizace modelu pro určitého Týmového poskytovatele:

Následující úseky kódu XML znázorňují registraci třídy účastníka CVS a definování jejího prohlížeče.

   <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>

Historie souborů

Rozhraní API historie souborů bylo přidáno s cílem poskytnout modelům přístup k historii souborů. Rozhraní API historie souborů se skládá z následujících rozhraní:

Společně s tímto rozhraním API byl přidán pohled Historie generického souboru. Tento pohled umožňuje týmovým poskytovatelům zobrazovat historii souboru/prostředku ve sdíleném pohledu a rovněž umožňuje modelům zobrazovat historii prvků modelu, které nejsou mapovány přímo na soubory. Pohled historie je pohled na bázi stránky, který získává stránku pro vybraný prvek následujícím způsobem:

Schopnost sady projektů

Do ProjectSetCapability byly přidány metody pro podporu přechodu mezi řetězcem odkazu používaným pro identifikaci mapování mezi projektem a vzdáleným obsahem a rozhraními URI, která identifikují schéma systému souborů registrované pomocí bodu rozšíření org.eclipse.core.filesystem.filesystems. Týmoví poskytovatelé mohou volitelně poskytovat podporu pro tuto možnost, aby mohly logické modely provádět vzdálené procházení a načítání projektů.

Zdobení prvků modelu

Týmoví poskytovatelé mohou zdobit prvky modelů převedením jejich odlehčených dekorátorů pro fungování s mapováním prostředků, podobně jako jsou takto převáděny příspěvky objektů. Jeden aspekt zdobení prvku logického modelu je ovšem problematický. Pokud prvek modelu nemá jedinečné mapování na prostředek, nemusí při změně základních prostředků obdržet aktualizaci štítku.

Ve snaze o vyřešení této záležitosti byl představen ITeamStateProvider, který umožňuje poskytovatelům modelů přístup ke změnám stavu, které mohou ovlivnit zdobení týmu. Kromě toho mohou pohledy modelů použít SynchronizationStateTester pro zjištění, kdy musí být štítky prvků logických modelů aktualizovány. Toto API závisí na rozhraní ITeamStateProvider při zjišťování, zda se týmový stav prostředku změnil a zda může být předán na týmový dekorátor jako součást IDecorationContext.