Pro zajištění plné podpory logických modelů může poskytovatel úložiště provést následující kroky:
ResourceMapping
.ISynchronizationScope
a podpůrného rozhraní API.IMergeContext
a podpůrného rozhraní API.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
.IFileHistoryProvider
ProjectSetCapability
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.
Rozhraní API mapování prostředků se skládá z následujících tříd:
Object getModelObject()
: Modelový objekt, ze kterého bylo mapování
odvozeno (nebo adaptováno).ResourceTraversal[]
getTraversals(ResourceMappingContext, IProgressMonitor)
: Průchod prostředku pokrývající prostředky, které tvoří modelový objekt.ResourceTraversal
obsahuje soubor prostředků a příznak hloubky udávající míru, do jaké jsou prostředky v průchodu asociovány s původním modelovým objektem. Průchody prostředků jsou poskytovány klientu prostřednictvím mapování prostředků za účelem popsání obsahu modelu takovým způsobem, aby mohl klient (např. poskytovatel úložiště) provádět své operace co možná nejefektivněji. Zkoumané metody jsou:
getResources()
getDepth()
ResourceMappingContext
a
RemoteResourceMappingContext
je poněkud komplikovanější a je popsáno později.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.
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
:
ResourceMapping
namísto IResource
(pro ty, kterých se to týká).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.
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:
ISynchronizationScope
:
Rozhraní, které definuje API pro přístup k rozsahu operace. Poskytuje přístup ke všem mapováním prostředků, na kterých jsou prováděny operace a k průchodům pro tato mapování, jak byly vypočítány během procesu vytváření
rozsahu.ISynchronizationScopeManager
:
Rozhraní, které definuje API pro vytváření a správu rozsahu.SynchronizationScopeManager
:
Rozšiřitelná třída, která poskytuje výchozí implementaci rozhraní API ISynchronizationScopeManager
.ModelOperation
:
Rozšiřitelná třída operace, která generuje rozsah pomocí správce rozsahu a zobrazuje upozornění, pokud byly do operace zahrnuty další prostředky nebo mapování v důsledku vztahů poskytovatelů modelů.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:
RemoteResourceMappingContext
pro použití při získávání průchodů prostředků z mapování prostředků.SynchronizationScopeManager
pro přizpůsobení procesu správy rozsahu podle potřeby.Následující dva oddíly popisují tyto body podrobněji.
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.
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:
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.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ů.
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.
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.
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:
ModelOperation
poskytuje výzvu, která prostřednictvím registrovaných poskytovatelů týmového obsahu informuje uživatele o rozšíření rozsahu.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:
ModelSynchronizeParticipant
ISynchronizePageConfiguration.P_VIEWER_ID
na ID prohlížeče uvedeného v předchozím kroku.MergeActionGroup
za účelem přizpůsobení vzhledu akcí souvisejících se sloučením.ModelParticipantMergeOperation
pro obsluhování přechodu ze sloučení na bázi modelů na náhled v dialogovém okně nebo v pohledu Synchronizovat.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>
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:
RepositoryProvider
přiřazeného k projektu obsahujícího prostředek na IHistoryPageSource.
IHistoryPageSource
.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ů.
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
.