Plan over opbevaringssted for logisk modelintegration

For at give fuld understøttelse til logiske modeller kan en udbyder af opbevaringssted gøre følgende:

  1. Knyt de relevante funktioner for opbevaringssted til elementer, der er tilpasser til ResourceMapping.
  2. Sørg for, at funktioner, der udføres på ressourcetilknytninger vha. mapping, inkluderer alle de relevante modelelementer og ressourcer ved at bruge en ISynchronizationScope og det understøttende API.
  3. Tillad modeludbydere at deltage i hovedløse fletninger via grænsefladen IMergeContext og det understøttende API.
  4. Tillad modeludbydere at deltage i fremvisning af resultater for flettefunktioner ved at bruge teamContentProviders for modellerne, der er involveret i flettefunktionen. En ModelSynchronizeParticipant-klasse stilles til rådighed for at hjælpe med at administrere relationen mellem modelindholdet, flettekontekst og strukturen Sammenlign.
  5. Stil adgang til rådighed for historikken for arbejdsområdefiler via API'et IFileHistoryProvider.
  6. Giv adgang til eksterne konfigurationer ved at bruge API'et for Eclipse-filsystemet i plugin'en org.eclipse.core.filesystem og link dette til arbejdsområdeprojekter via ProjectSetCapability
  7. Understøt dekoration af logiske modelelementer ved at stille et arbejdsområde - Subscriber - til brug sammen med API'et SynchronizationStateTester.

De følgende afsnit beskriver hvert af disse punkter mere detaljeret. Plugin'en org.eclipse.team.examples.filesystem indeholder et eksempel, der illustrerer adskillige af disse punkter. Du kan tjekke projektet ud fra CVS-opbevaringsstedet og bruge det som reference, mens du læser denne øvelse. Ansvarsfraskrivelse: Kildekoden i eksempelplugins kan ændres over tid. Hvis du vil hente en kopi, der matcher den, som bruges i dette eksempel, kan du tjekke projektet ud ved brug af 3.0-versionskoden (sandsynligvis R3_2) eller datokoden 28. juni 2006.

Tilknyt funktioner til ressourcetilknytninger vha. mapping

API'et for grundlæggende ressource-mapping

Ressource-mapping-API'et består af følgende klasser:

To typer plugins har interesse i ressourcetilknytninger vha. mapping. Dem, der stiller en model til rådighed eller er en del af ressourcer i et arbejdsområde, eller dem, der udfører funktioner på ressourcer. Den første case behandles i Modelplan for logisk modelintegration og den sidste case behandles i næste afsnit.

Ressourcetilknytninger vha. mapping og objektbidrag

Plugins, der leverer udvidelser til udvidelsespunkter, der skal tilpasses, skal foretage to ændringer for at understøtte de nye ResourceMapping-API'er.

  1. Opdatér alle objectContributions for udvidelsespunktet popupMenus i deres plugin.xml-filer, så de retter sig mod ResourceMapping i stedet for IResource (hvis det er relevant for dem).
  2. Opdatér deres funktioner til at arbejde på ResourceMapping i stedet for IResource og til at respektere dybdebetingelserne, der stilles til rådighed i gennemløbene.

Plugins, der tilføjer objektbidrag til IResource, kan nu tilføje dem til ResourceMapping i stedet for, hvis funktionen kan knyttes til flere ressourcer. Nedenfor er et XML-stykke, der bidrager til en menufunktion til objekter, der tilpasser sig til ressourcetilknytninger vha. mapping.

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

Bidrag til ResourceMapping anvendes automatisk til objekter, der tilpasser sig til IResource. Denne transitive association håndteres af arbejdsbænken. Filtrering af bidragene til ressourcetilknytningerne vha. mapping kan foretages ved at bruge aktiveringsudtryk. Et udtryk for filtrering af vedvarende projektegenskaber er blevet tilføjet for at tillade udbydere af opbevaringssteder at få deres menuer vist i projekter, der er tilknyttet vha. mapping til deres opbevaringssteder.

Funktioner, der er leveret til klassen ResourceMapping får tildelt et valg, der indeholder én eller flere ResourceMappings. Det er funktionens ansvar at konvertere ressource-mapping'en til et sæt ressourcer, der skal arbejdes fra. Det kan gøres ved at kalde getTraversals for at få gennemløb af mapping'en. Gennemløb anvendes til at tillade gennemløbets klienter at optimere deres funktioner baseret på dybden af de ressourcer, der gennemløbes. En klient kan gennemløbe ressourcen manuelt eller kan bruge ressourcen og dybden som input i en operation, som funktionen delegerer til at udføre jobbet. Hvis brugeren f.eks. udfører en CVS-opdatering på en Java-pakke, og ressource-mapping'en for Java-pakken tilknytter til en folder med dybden én vha. mapping, vil CVS sende en tilsvarende kommando ("cvs update -l"), der udfører en overfladisk opdatering på den folder, pakken repræsenterer.

Selvom det er muligt at hente et sæt gennemløb direkte fra de valgte ressourcetilknytninger vha. mapping, er der modelrelationer eller opbevaringsstedsrelationer, der kan kræve inkludering af ekstra ressourcer eller modelelementer i en funktion. Det næste afsnit beskriver, hvordan du sikrer, at alle nødvendige ressourcer er inkluderet i en funktion.

Funktionsomfang

For teamfunktioner skal de valgte tilknytninger vha. mapping konverteres til et sæt tilknytninger, der kan arbejdes fra. Denne proces involverer konsultation af alle modeludbydere for at sikre, at de inkluderes i funktioner for ressourcer, der matcher deres aktiveringsregler. Begrebet, der anvendes til at beskrive det komplette sæt ressourcetilknytninger vha. mapping, der skal arbejdes ud fra, er funktionen omfang. Det følgende API er stillet til rådighed for følgende:

Metoden initialize(IProgressMonitor) for klassen SynchronizationScopeManager håndterer hele processen med konvertering af inputsæt af ressourcetilknytninger vha. mapping til komplette sæt af tilknytninger, der skal arbejdes ud fra, og komplette sæt af gennemløb, der dækker disse tilknytninger. En udbyder af opbevaringssted kan tilpasse processen ved at:

  1. Stille en RemoteResourceMappingContext til rådighed, der kan bruges ved hentning af ressourcegennemløb fra ressourcetilknytninger vha. mappings.
  2. Tilsidesætte SynchronizationScopeManager for at tilpasse omfangsstyringen som påkrævet.

De næste to afsnit beskriver disse punkter mere detaljeret.

Kontekst for ekstern ressource-mapping

For at garantere, at alle nødvendige ressourcer inkluderes i en teamfunktion, kan modeludbyderen have brug for at få et indtryk af tilstanden for en eller flere ressourcer i opbevaringsstedet. For visse modeller er dette ikke påkrævet. F.eks. er en Java-pakke et opbevaringssted, der besøges med en dybde på én, uanset modellens eksterne tilstand. Forudsat dette kan en udbyder af opbevaringssted nemt bestemme, at udgående sletninger kan inkluderes ved commit, eller at indgående tilføjelser skal inkluderes ved opdatering. Ressourcerne, der konstituerer visse logiske modeller, kan imidlertid ændres efterhånden. F.eks. kan de ressourcer, der konstituerer en model, være afhængige af indholdet af en manifestfil eller en anden tilsvarende mekanisme. For at ressource-mapping skal returnere det korrekte gennemløb skal den have adgang til det eksterne indhold af manifestfilen, hvis det afviger fra det lokale indhold, for at undersøge, om der skal inkluderes ekstra ressourcer. Disse ekstra ressourcer findes måske ikke i arbejdsområdet, men udbyderen af opbevaringsstedet vil vide, hvordan man sikrer sig, at det fandtes, da den valgte funktion blev udført.

For at understøtte disse mere komplekse modeller kan en RemoteResourceMappingContext sendes til metoden ResourceMapping#getTraversals. Når en kontekst stilles til rådighed, kan mapping'en bruge den til at sikre, at alle nødvendige ressourcer er inkluderet i gennemløbet. Hvis der ikke er en kontekst, kan mapping'en antage, at kun den lokale tilstand er af interesse.

Konteksten for den eksterne ressource-mapping stiller tre grundlæggende spørgsmål:

Svaret på det første spørgsmål ovenfor afhænger af den type funktion, der udføres. Normalt er opdateringer og flettefunktioner trevejs, mens sammenligninger og erstatfunktioner (i det mindste for CVS) er tovejs.

Eclipse Team-API'et indeholder en Subscriber-klasse, der definerer et API, der stiller synkroniseringstilstanden mellem det lokale arbejdsområde og den eksterne server til rådighed. En SubscriberResourceMappingContext stilles til rådighed, der anvender en Subscriber til at få adgang til den påkrævede eksterne tilstand. Klienter, der har en Subscriber, behøver ikke udføre noget yderligere arbejde for at hente konteksten til en ressource-mapping.

Inddeling af SynchronizationScopeManager i underklasser

Klassen SynchronizationScopeManager kan inddeles i underklasser for at tilpasse omfangsgenerering og styringsprocesser. De to hovedgrunde til at inddele omfangsstyringen i underklasser er:

  1. Udbyderen af opbevaringsstedet skal inkludere ekstra ressourcer pga. relationer til niveau for opbevaringssted (f.eks. ændringssæt). Det kan opnås ved at tilsidesætte metoden adjustInputTraversals(ResourceTraversal[]).
  2. Synkroniseringen har en længere livscyklus (f.eks. synkroniseringsoversigt overfor dialogboks) og skal have potentialet til at reagere på omfangsændringer. Grænsefladen ISynchronizationScopeParticipant definerer det API, som modeludbydere kan bruge til at deltage i styringsprocessen for omfang. Klassen SubscriberScopeManager er en Subscriber-baseret underklasse af SynchronizationScopeManager, der involverer deltagere i styringsprocessen for omfang. Arbejdssæt er et eksempel på, hvorfor denne type proces er nødvendig. Hvis et arbejdssæt er en af ressourcetilknytningerne vha. mapping i et omfang, øges sættet af gennemløb, der dækkes af omfanget, hvis der føjes ressourcer til arbejdssættet.

Modelbaseret fletning

Funktionstypen for hovedopbevaringsstedet, der kræver modeldeltagelse, udfører fletningen. I mange tilfælde behøver modeller kun at deltage på filniveau. Af hensyn til dette blev IStorageMerger-API'et introduceret for at tillade modeludbydere at levere sammenfletninger, der skal anvendes til at flette filer med en bestemt udvidelses- eller indholdstype. I visse tilfælde kan modeller have behov for ekstra kontekst for at deltage korrekt i en fletning. Af hensyn til dette har vi introduceret API'erne IResourceMappingMerger og IMergeContext.

Flettefunktioner udløses stadig af funktioner, der er knyttet til en udbyder af opbevaringssteder. Når en bruger imidlertid én gang har anmodet om en flettetypefunktion, skal udbyderen af opbevaringsstedet involvere modeludbydere i fletteprocessen for at sikre, at flettefunktionen ikke ødelægger modellen på en eller anden måde.

Der er to hoveddele af udbydere af opbevaringssteds-API'er med relation til den modelbaserede fletteunderstøttelse.

  1. Et API til at beskrive synkroniseringstilstanden af den ressource, der er involveret i flettefunktionen.
  2. Et API, der tillader modeludbydere at flette modelelementer.
De følgende afsnit beskriver de to dele.

API til beskrivelse af synkroniseringstilstand

Et vigtigt aspekt af modelbaseret fletning er det API, der anvendes til at kommunikere synkroniseringstilstanden for ressourcer, der er involveret, til modeludbyderen. Følgende grænseflader anvendes til at beskrive synkroniseringstilstanden:

Abstrakte klasser stilles til rådighed for alle de grænseflader med den konvention, at klassenavnene matcher grænsefladenavnene, hvor præfikset "I" er fjernet. Den eneste klasse, som udbydere af opbevaringssteder skal tilsidesætte, er klassen ResourceDiff, så passende før- og efter-filrevisioner kan stilles til rådighed.

API til modelfletning

Grænsefladen IMergeContext udvider synkroniseringskonteksten med ekstra metoder, der understøtter fletning. Tilbagekaldsmetoder findes for:

En abstrakt MergeContext-klasse stilles til rådighed, der indeholder standardimplementeringer for mange flettefunktionsmåder, og som også bruger IStorageMerger til at udføre trevejsfletning. En SubscriberMergeContext-klasse stilles også til rådighed, der håndterer udfyldning og vedligeholdelse af synkroniseringstilstandsbeskrivelser, der er knyttet til flettekonteksten.

En funktionsklasse, ModelMergeOperation, stilles til rådighed, der anvender IResourceMappingMerger API til at udføre en modelbaseret flettefunktion. Underklasser skal tilsidesætte metoden initializeContext(IProgressMonitor) for at returnere en flettekontekst. Funktionen bruger denne kontekst til at forsøge en hovedløs modelbaseret fletning. Hvis der er konflikter, overlades det til underklassen at vise resultatet af fletningen. Som det fremgår af næste afsnit, er der en ModelParticipantMergeOperation, der stiller mulighed for at vise resultat til rådighed vha. en ModelSynchronizeParticipant.

Modelindhold i oversigter over teamfunktioner

Understøttelse af fremvisning af logiske modeller i en teamfunktion stilles til rådighed ved at bruge strukturen Common Navigator, der blev introducereti Eclipse 3.2. Logiske modeller kan knytte en indholdsudvidelse til en modeludbyder vha. udvidelsespunktet org.eclipse.team.ui.teamContentProvider. Teamudbydere har adgang til disse indholdsudbydere gennem ITeamContentProviderManager.

Der er flere steder, hvor en teamudbyder kan ønske at få vist logiske modeller:

ModelSynchronizeParticipant stiller integration med oversigten Synkronisér til rådighed eller med ethvert opbevaringssted, der kan vise iSynchronizePages. Deltageren gør brug af mulighederne i både den allerede eksisterende synkroniseringsdeltager og Common Navigator for at gøre det muligt for teamudbydere og modeller at tilpasse værktøjslinjen, kontekstmenuen og andre aspekter af fletteoversigten. ModelSynchronizeParticipant indeholder følgende:

Nedenfor er en tjekliste over tilpasning af en modelsynkroniseringsdeltager til en bestemt teamudbyder:

Følgende XML-stykke viser, hvordan CVS-deltagerklassen er registreret, og hvordan dens fremviser er defineret.

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

Filhistorik

Et filhistorik-API er tilføjet og tillader modeller adgang til filhistorikken. Filhistorik-API'et består af følgende grænseflader:

Sammen med dette API er en ny oversigt over filhistorik tilføjet. Det tillader teamudbydere at få vist deres fil/ressourcehistorik i en fælles oversigt og tillader også modeller at vise modelelementhistorik for elementer, der ikke knytter sig direkte til filer. Oversigten Historik er en sidebaseret oversigt, der henter en side for det valgte element på følgende måde:

Projektsætmuligheder

Der er tilføjet metoder til ProjectSetCapability for at understøtte konverteringen mellem en referencestreng, der anvendes til at angive en mapping mellem et projekt og eksternt indhold og URI'er, der angiver et filsystemskema, der er registreret med udvidelsespunktet org.eclipse.core.filesystem.filesystems. Teamudbydere kan valgfrit stille understøttelse til rådighed for at tillade logiske modeller at udføre eksternt gennemsyn og projektindlæsning.

Dekoration af modelselementer

Teamudbydere kan dekorere modelelementer ved at konvertere deres letvægtsdekoratører til at arbejde for ressource-mappings, på samme måde som objektbidrag konverteres til at arbejde for ressource-mappings. Der er imidlertid et aspekt af logisk modelelementdekoration, der er problematisk. Hvis et modelelement ikke har en én-til-én-mapping til en ressource, modtager modelelementet måske ikke etiketopdatering, når den underliggende ressource ændres.

For at løse problemet er ITeamStateProvider introduceret for at give modeludbydere adgang til tilstandsændringer, der kan påvirke teamdekorationer. Desuden kan modeloversigter anvende en SynchronizationStateTester til at bestemme, hvornår etiketter for logiske modelelementer skal opdateres. Dette API er afhængigt af grænsefladen ITeamStateProvider, når det skal bestemmes, hvornår teamtilstanden for ressourcen er ændret og kan sendes til en teamdekoratør som en del af en IDecorationContext.