Om volledige ondersteuning te bieden aan logische modellen, kan een repositoryprovider de volgende stappen uitvoeren:
ResourceMapping
.ISynchronizationScope
en een ondersteunende API.IMergeContext
en ondersteunende API. teamContentProviders
te gebruiken voor de modellen die betrokken zijn bij de samenvoeging. De klasse ModelSynchronizeParticipant
is verstrekt om te helpen bij het beheren van de relatie tussen de modelcontent, een
samenvoegingscontext en het vergelijkingsframework. IFileHistoryProvider
-APIProjectSetCapability
koppelen aan werkgebiedprojecten. abonnee
te bieden om met de SynchronizationStateTester
-API te gebruiken.In de volgende secties worden al deze punten gedetailleerder beschreven. De plugin org.eclipse.team.examples.filesystem bevat een voorbeeld dat verschillende van deze punten illustreert. U kunt het project uit de CVS-repository reserveren en als naslag gebruiken tijdens het lezen van deze zelfstudie. Let op: de broncode in de voorbeeldplugins kan van tijd tot tijd worden gewijzigd. Als u een exemplaar wilt bemachtigen dat met dit voorbeeld overeenkomt, kunt u het project reserveren met de 3.2-versiecode (waarschijnlijk R3_2) of de datumcode 28 juni 2006.
De resourcetoewijzings-API bestaat uit de volgende klassen:
Object getModelObject()
: het modelobject waarvan de toewijzing is afgeleid (of aangepast).ResourceTraversal[]
getTraversals(ResourceMappingContext, IProgressMonitor)
: de resource-uitvoering die de resources beslaat die het modelobject vormen.ResourceTraversal
bevat een set met resources en een dieptevlag die de diepte aangeeft waarop de resources in de uitvoering aan het oorspronkelijke modelobject zijn gekoppeld. Resource-uitvoeringen worden door een resourcetoewijzing aan een client verstrekt om de content van een model op zo'n manier te beschrijven dat de client (bijvoorbeeld een repositoryprovider) zijn bewerkingen zo efficiënt mogelijk kan uitvoeren. De volgende methoden zijn van belang:
getResources()
getDepth()
ResourceMappingContext
en RemoteResourceMappingContext
is iets gecompliceerder en wordt later beschreven.Er zijn twee typen plugins waarvoor resourcetoewijzingen interessant zouden moeten zijn. Plugins die een model leveren dat bestaat uit resources of resources bevat in het werkgebied en plugins die bewerkingen op resources willen uitvoeren. Het eerste type wordt besproken in in de modelwegwijzer en het tweede type wordt behandeld in de volgende sectie.
Plugins die extensies bijdragen aan aanpasbare extensiepunten, moeten twee wijzigingen doorvoeren om de nieuwe ResourceMapping
-API's te kunnen ondersteunen:
ResourceMapping
in plaats van naar IResource
(voor de plugins waarvoor dit van toepassing is). ResourceMapping
in plaats van op
IResource
en de dieptebeperkingen te respecteren die in de uitvoeringen van toepassing zijn.Plugins die objectbijdragen toevoegen aan IResource
kunnen ze nu in plaats daarvan toevoegen aan ResourceMapping
, als de actie op meerdere resources van toepassing kan zijn. Hier volgt een XML-snippet dat een menuactie bijdraagt aan objecten die zich aanpassen aan resourcetoewijzingen:
<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>
Bijdragen aan ResourceMapping
zullen automatisch van toepassing zijn op objecten die zich aanpassen aan IResource
. Deze transitieve koppeling wordt afgehandeld door de workbench. Het filteren van de bijdragen aan resourcetoewijzingen kan worden uitgevoerd met behulp van beschikbaarheidsvoorwaarden. Er is een voorwaarde voor het filteren per projectspecifieke eigenschap toegevoegd om repositoryproviders de mogelijkheid te bieden hun menu's in projecten weer te geven die aan hun repository's zijn toegewezen.
Acties die aan de klasse ResourceMapping
zijn aangeboden, krijgen een selectie die een of meer ResourceMappings
bevat.
Het is de verantwoordelijkheid van de actie om de resourcetoewijzing om te zetten in een set resources waarop bewerkingen kunnen worden uitgevoerd. Dit kan worden gedaan door getTraversals
aan te roepen om de uitvoeringen van de toewijzing op te halen. Uitvoeringen worden gebruikt om de clients van de uitvoering in staat te stellen hun bewerkingen te optimaliseren op basis van de diepte van de resources die worden uitgevoerd. Een client kan de resource handmatig uitvoeren of de resource en de diepte als invoer gebruiken voor een bewerking waarnaar de actie de activiteiten delegeert. Als de gebruiker bijvoorbeeld een CVS-update uitvoert op een Java-pakket en de resourcetoewijzing van het Java-pakket wordt toegewezen aan een map met een diepte van één, geeft CVS de juiste opdracht ("cvs update -l" voor de nieuwsgierige), waarmee een oppervlakkige update wordt uitgevoerd op de map die het pakket vertegenwoordigt.
Hoewel het mogelijk is om een set uitvoeringen direct uit de geselecteerde resourcetoewijzingen op te halen, zijn er modelrelaties (of repositoryrelaties) die mogelijk vereisen dat er aanvullende resources of modelelementen in een bewerking zijn opgenomen. In de volgende sectie wordt beschreven hoe u er zeker van kunt zijn dat alle vereiste resources in een bewerking zijn opgenomen.
Voor teambewerkingen moeten de geselecteerde toewijzingen worden omgezet in de set toewijzingen die moet worden bewerkt. Voor dit proces moeten alle modelproviders worden geraadpleegd om er zeker van te zijn dat deze worden opgenomen in bewerkingen op resources die overeenkomen met hun beschikbaarheidsregels. De term die wordt gebruikt om de volledige set resourcetoewijzingen te beschrijven die moet worden bewerkt, is het bewerkingsbereik. Hiervoor is de volgende API geleverd:
ISynchronizationScope
:
een interface die de API definieert voor het evalueren van het bereik van de bewerking. Deze biedt toegang tot alle resourcetoewijzingen die worden bewerkt en de uitvoeringen voor deze toewijzingen alsof ze tijdens het proces van het opbouwen van het bereik waren berekend.ISynchronizationScopeManager
:
een interface die de API definieert voor het maken en beheren van een bereik.SynchronizationScopeManager
:
een uitbreidbare klasse die een standaardimplementatie van de ISynchronizationScopeManager
-API biedt.ModelOperation
:
een uitbreidbare bewerkingsklasse die een bereik genereert met behulp van een opgegeven bereikmanager en om invoer vraagt als er aanvullende resources of toewijzingen zijn opgenomen in de bewerking naar aanleiding van relaties tussen modelproviders.De methode initialize(IProgressMonitor) van de klasse SynchronizationScopeManager
verwerkt het gehele proces van het converteren van een invoerset van resourcetoewijzingen in de volledige set toewijzingen die moet worden bewerkt, plus de volledige set uitvoeringen die deze toewijzingen beslaan. Een repositoryprovider kan het proces op maat maken door:
RemoteResourceMappingContext
te verstrekken die kan worden gebruikt wanneer resource-uitvoeringen worden opgehaald uit resourcetoewijzingen.SynchronizationScopeManager
te wijzigen om het bereikbeheerproces indien nodig op maat te maken.In de volgende twee secties worden deze punten gedetailleerder beschreven.
Om te kunnen garanderen dat alle noodzakelijke resources in een teambewerking worden opgenomen, moet de modelprovider misschien over de mogelijkheid beschikken om de status van een of meer resources in de repository te bekijken. Voor sommige modellen is dit misschien niet verplicht. Een Java-pakket is bijvoorbeeld een container die wordt bezocht tot een diepte van één, ongeacht de status op afstand van het model. Met dit gegeven kan een repositoryprovider eenvoudig vaststellen dat uitgaande verwijderingen moeten worden opgenomen bij het vastleggen of dat inkomende aanvullingen moeten worden opgenomen bij het bijwerken. De resources die bepaalde logische modellen vormen, kunnen echter wijzigen na verloop van tijd. De resources die een modelelement vormen, hangen bijvoorbeeld mogelijk af van de content van een manifestbestand (of een ander vergelijkbaar mechanisme). Om de resourcetoewijzng de juiste uitvoering te laten retourneren, moet deze de content op afstand van het manifestbestand openen (als dit verschilt van de lokale content) om te zien of er aanvullende resources zijn die moeten worden opgenomen. Deze aanvullende resources bestaan mogelijk niet in het werkgebied, maar de repositoryprovider weet hoe hij er zeker van kan zijn dat deze wel aanwezig waren op het moment dat de geselecteerde actie is uitgevoerd.
Voor de ondersteuning van deze complexere modellen kan een RemoteResourceMappingContext
worden doorgegeven aan de methode ResourceMapping#getTraversals
.
Wanneer een context wordt verstrekt, kan de toewijzing deze gebruiken om te controleren of alle noodzakelijke resources in de toewijzing zijn opgenomen. Als er geen context is verstrekt, kan de toewijzing aannemen dat alleen de lokale status van belang is.
De resourcetoewijzingscontext op afstand biedt drie basisquery's:
Het antwoord op de eerste vraag hangt af van het type bewerking dat wordt uitgevoerd. Doorgaans zijn updates en samenvoegingen in drie richtingen, terwijl vergelijkings- en vervangingsbewerkingen (in ieder geval voor CVS) in twee richtingen zijn.
De Eclipse-team-API omvat een abonnee
klasse die een API definieert voor het verstrekken van de synchronisatiestatus tussen het lokale werkgebied en een server op afstand. Er wordt een SubscriberResourceMappingContext
geboden die gebruikmaakt van een abonnee
om de noodzakelijke status op afstand te openen. Clients die een abonnee
hebben, hoeven geen aanvullende bewerkingen uit te voeren om een resourcetoewijzingscontext op te halen.
De klasse SynchronizationScopeManager
kan in subklassen worden onderverdeeld om het genereren van het bereik en het beheerproces op maat te maken. De twee belangrijkste redenen om de bereikmanager in subklassen onder te verdelen, zijn:
ISynchronizationScopeParticipant
definieert de API die modelproviders kunnen gebruiken om deel te nemen aan het bereikbeheerproces. De klasse SubscriberScopeManager
is een op een abonnee
gebaseerde subklasse van SynchronizationScopeManager
die deelnemers in het bereikbeheerproces omvat. Een voorbeeld van waarom dit type proces nodig is, wordt gevormd door werksets. Als een werkset een van de resourcetoewijzingen in een bereik is, neemt de set met uitvoeringen die binnen het bereik valt toe als resources aan de werkset worden toegevoegd.Samenvoeging is het belangrijkste type repositorybewerking waarvoor modeldeelname vereist is. In veel gevallen hoeven modellen alleen deel te nemen op het bestandsniveau. Hiervoor is de IStorageMerger
-API geïntroduceerd om modelproviders de mogelijkheid te bieden samenvoegers bij te dragen die zouden moeten worden gebruikt om bestanden met een bepaalde extensie of type content samen te voegen. In sommige gevallen hebben modellen mogelijk extra context nodig om op de juiste wijze aan een samenvoeging te kunnen deelnemen. Voor dit doel hebben we de IResourceMappingMerger
- en
IMergeContext
-API's geïntroduceerd.
Samenvoegingsbewerkingen worden nog steeds geactiveerd door acties die aan een repositoryprovider zijn gekoppeld. Wanneer een bewerking van het type samenvoeging echter wordt aangevraagd door de gebruiker, moet de repositoryprovider de modelproviders betrekken in het samenvoegingsproces om er zeker van te zijn dat de samenvoeging het model niet op de een of andere manier beschadigt.
Er zijn twee belangrijke delen van de repositoryprovider-API die gerelateerd zijn aan de ondersteuning voor samenvoeging op basis van modellen.
Een belangrijk aspect van samenvoeging op basis van modellen is de API die wordt gebruikt om de synchronisatiestatus van de betrokken resources aan de modelprovider te communiceren. De volgende interfaces worden gebruikt om de synchronisatiestatus te beschrijven:
Voor al deze interfaces worden abstracte klassen geleverd, waarbij is afgesproken dat de klassenamen overeenkomen met de interfacenamen, maar dat het voorvoegsel "I" is verwijderd. De enige klasse die repositoryproviders moeten vervangen is de klasse ResourceDiff
, zodat de juiste bestandsrevisies voor vóór en na kunnen worden geleverd.
De interface IMergeContext breidt de synchronisatiecontext uit met aanvullende methoden die samenvoegen ondersteunen. Er bestaan callbackmethoden voor:
Er is een abstracte klasse meegeleverd, MergeContext, die standaardimplementaties bevat voor veel van het samenvoegingsgedrag en ook de IStorageMerger om samenvoegingen in drie richtingen uit te voeren. Er is ook de klasse SubscriberMergeContext meegeleverd die de invulling en het beheer van de beschrijving van de synchronisatiestatus die is gekoppeld aan de samenvoegingscontext afhandelt.
Er wordt een bewerkingsklasse, ModelMergeOperation
geleverd die gebruikmaakt van de IResourceMappingMerger
-API om een op een model gebaseerde samenvoegingsbewerking uit te voeren. Subklassen moeten de methode initializeContext(IProgressMonitor)
vervangen om een samenvoegingscontext te retourneren. De bewerking gebruikt deze context om een naamloze op een model gebaseerde samenvoeging te proberen uit te voeren. Als er conflicten bestaan, wordt de preview van de samenvoeging overgelaten aan de subklasse. Zoals we in de volgende sectie zullen zien, is er een ModelParticipantMergeOperation
die nieuwe previewmogelijkheden biedt met behulp van een ModelSynchronizeParticipant.
Er wordt ondersteuning voor de weergave van logische modellen in een teambewerking geleverd met behulp van het algemene navigatornetwerk dat is geïntroduceerd in
Eclipse 3.2. Logische modellen kunnen een contentextensie koppelen aan een modelprovider met behulp van het extensiepunt org.eclipse.team.ui.teamContentProvider. Teamproviders hebben toegang tot deze contentproviders via de ITeamContentProviderManager
.
Er zijn verschillende locaties waar een teamprovider logische modellen mogelijk wenst weer te geven:
ModelOperation
biedt een prompt die de geregistreerde teamcontproviders gebruikt om de gebruiker over een uitbreiding van een bereik te informeren. De ModelSynchronizeParticipant
biedt integratie in de synchronisatieview of elke andere container die iSynchronizePages
kan weergeven.
De deelnemer maakt zowel gebruik van de eerder bestaande synchronisatiedeelnamemogelijkheden als de algemene navigatormogelijkheden om teamproviders en modellen in staat te stellen de werkbalk, het voorgrondmenu en andere aspecten van de samenvoegingspreview op maat te maken. De ModelSynchronizeParticipant
biedt het volgende:
Hieronder volgt een controlelijst met stappen voor het op maat maken van een synchronisatiedeelnemer van een model voor een bepaalde teamprovider:
ModelSynchronizeParticipant
te maken. ISynchronizePageConfiguration.P_VIEWER_ID
in te stellen op het ID van de viewer die in de voorgaande stap is opgegeven. MergeActionGroup
om de weergave van de aan de samenvoeging gerelateerde acties op maat te maken.ModelParticipantMergeOperation
voor het verwerken van de overgang van een op een model gebaseerde samenvoeging naar een preview in een dialoogvenster of synchronisatieview.De volgende XML-snippets illustreren hoe de CVS-deelnemerklasse wordt geregistreerd en hoe de viewer ervan wordt gedefinieerd.
<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>
Er is een bestandshistorie-API toegevoegd om modellen de mogelijkheid te bieden toegang te krijgen tot de historie van bestanden. De bestandshistorie_API bestaat uit de volgende interfaces:
Samen met deze API is een generieke bestandshistorieview toegevoegd. Deze biedt teamproviders de mogelijkheid hun bestands-/resourcehistorie in een gedeelde view te bekijken en stelt ook modellen in staat om de modelelementhistorie weer te geven voor elementen die niet direct aan bestanden zijn toegewezen. De historieview is een op een pagina gebaseerde view die op de volgende manier een pagina ophaalt voor het geselecteerde element:
RepositoryProvider
die is gekoppeld aan het project dat de resource bevat, aan te passen aan een IHistoryPageSource.
IHistoryPageSource
.Er zijn methoden toegevoegd aan ProjectSetCapability
ter ondersteuning van de omzetting tussen een referentietekenreeks die wordt gebruikt om een toewijzing tussen een project en content op afstand te identificeren en URI's die een bestandssysteemschema identificeren dat is geregistreerd bij het extensiepunt
org.eclipse.core.filesystem.filesystems. Teamproviders kunnen optioneel ondersteuning bieden hiervoor om logische modellen de mogelijkheid te bieden te bladeren op afstand en projecten te laden.
Teamproviders kunnen modelelementen decoreren door hun lichtgewicht decorators te converteren om op dezelfde manier te werken met resourcetoewijzingen als objectbijdragen worden geconverteerd om voor resourcetoewijzingen te kunnen worden gebruikt. Er is echter een aspect van logische modelelementdecoratie die problematisch is. Als een model geen één-op-één toewijzing met een resource heeft, ontvangt het modelelement mogelijk geen labelupdate wanneer de onderliggende resource wijzigt.
Om dit probleem aan te pakken, is de ITeamStateProvider
geïntroduceerd om modelproviders toegang te bieden tot statuswijzigingen die mogelijk van invloed zijn op teamdecoraties. Bovendien kunnen modelviews een SynchronizationStateTester
gebruiken om vast te stellen wanneer de labels van logische modelelementen moeten worden bijgewerkt. Deze API is afhankelijk van de interface ITeamStateProvider
om vast te stellen of de teamstatus is gewijzigd en kan worden doorgegeven aan een
teamdecorator als onderdeel van IDecorationContext
.