Repositorywegwijzer voor logische modelintegratie

Om volledige ondersteuning te bieden aan logische modellen, kan een repositoryprovider de volgende stappen uitvoeren:

  1. De juiste repositorybewerkingen toevoegen aan elementen die zich aanpassen aan ResourceMapping.
  2. Ervoor zorgen dat bewerkingen die worden uitgevoerd op resourcetoewijzingen alle juiste modelelementen en resources bevatten door gebruik te maken van een ISynchronizationScope en een ondersteunende API.
  3. Modelproviders de mogelijkheid bieden deel te nemen aan naamloze samenvoegingen via de interface IMergeContext en ondersteunende API.
  4. Modelproviders de mogelijkheid bieden om deel te nemen aan samenvoegingspreviews door de 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.
  5. Toegang bieden tot de historie van werkgebiedbestanden via de IFileHistoryProvider-API
  6. Toegang bieden tot configuraties op afstand met behulp van de Eclipse-bestandssysteem-API in de plugin org.eclipse.core.filesystem en deze via ProjectSetCapability koppelen aan werkgebiedprojecten.
  7. Logische elementdecoratie ondersteunen door een werkgebiedabonnee 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.

Acties toevoegen aan resourcetoewijzingen

De basisresourcetoewijzings-API

De resourcetoewijzings-API bestaat uit de volgende klassen:

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.

Resourcetoewijzingen en objectbijdragen

Plugins die extensies bijdragen aan aanpasbare extensiepunten, moeten twee wijzigingen doorvoeren om de nieuwe ResourceMapping-API's te kunnen ondersteunen:

  1. Alle objectContributions van het extensiepunt popupMenus bijwerken in het bestand plugin.xml om te wijzen naar ResourceMapping in plaats van naar IResource (voor de plugins waarvoor dit van toepassing is).
  2. De acties bijwerken om bewerkingen uit te voeren op 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.

Bewerkingsbereik

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:

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:

  1. Een RemoteResourceMappingContext te verstrekken die kan worden gebruikt wanneer resource-uitvoeringen worden opgehaald uit resourcetoewijzingen.
  2. SynchronizationScopeManager te wijzigen om het bereikbeheerproces indien nodig op maat te maken.

In de volgende twee secties worden deze punten gedetailleerder beschreven.

Resourcetoewijzingscontext op afstand

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

SynchronizationScopeManager in subklassen onderdelen

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:

  1. De repositoryprovider moet aanvullende resources opnemen vanwege een bepaalde relatie op repositoryniveau (bijvoorbeeld een wijzigingsset). Dit kan worden gerealiseerd door de methode adjustInputTraversals(ResourceTraversal[]) te vervangen.
  2. De synchronisatie heeft een langere levenscyclus (bijvoorbeeld view versus dialoogvenster synchroniseren) en moet over de mogelijkheid beschikken om te reageren op wijzigingen in het bereik. De interface 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.

Samenvoegen op basis van modellen

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.

  1. Een API om de synchronisatiestatus van de bij de samenvoeging betrokken resources te beschrijven.
  2. Een API om modelproviders de mogelijkheid te bieden modelelementen samen te voegen.
In de volgende secties worden deze twee delen besproken.

API voor het beschrijven van de synchronisatiestatus

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.

API voor het samenvoegen van modellen

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.

Modelcontent in teamviewers

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:

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:

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>

Bestandshistorie

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:

Projectsetvoorziening

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.

Modelelementen decoreren

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.