For at give fuld understøttelse til logiske modeller kan en udbyder af opbevaringssted gøre følgende:
ResourceMapping
. ISynchronizationScope
og det understøttende API. IMergeContext
og det understøttende API.
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. IFileHistoryProvider
. ProjectSetCapability
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.
Ressource-mapping-API'et består af følgende klasser:
Object getModelObject()
: Modelobjektet, som mapping'en er afledt af (eller tilpasset efter). ResourceTraversal[] getTraversals(ResourceMappingContext, IProgressMonitor)
: Det ressourcegennemløb, der dækker de ressourcer, der konstituerer modelobjektet.
ResourceTraversal
indeholder et sæt ressourcer og et dybdeflag, der angiver dybden, som ressourcerne i gennemløbet er knyttet til, med det oprindelige modelobjekt.
Ressourcegennemløb stilles til rådighed for en klient af en ressource-mapping for at beskrive indholdet af en model på en måde, så klienten (f.eks. ressourceudbyderen) kan udføre sine funktioner så effektivt som muligt. De relevante metoder er:
getResources()
getDepth()
ResourceMappingContext
og RemoteResourceMappingContext
er lidt mere kompliceret og beskrives senere.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.
Plugins, der leverer udvidelser til udvidelsespunkter, der skal tilpasses, skal foretage to ændringer for at understøtte de nye ResourceMapping
-API'er.
ResourceMapping
i stedet for
IResource
(hvis det er relevant for dem).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.
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:
ISynchronizationScope
:
Grænseflade, der definerer API'et for adgang til omfanget for funktionen. Det stiller adgang til alle ressourcetilknytninger vha. mapping, der arbejdes fra, til rådighed, og gennemløbene for disse tilknytninger, da de blev beregnet under bygningen af omfang.
ISynchronizationScopeManager
:
Grænsefladen, der definerer API'et til oprettelse og administration af omfanget. SynchronizationScopeManager
:
Klasse, der kan udvides, og som stiller standardimplementeringen af API'et ISynchronizationScopeManager
til rådighed.
ModelOperation
:
Funktionsklasse, der kan udvides, og som genererer et omfang, der bruger den leverede omfangsstyring og spørger, hvis ekstra ressourcer eller tilknytninger vha. mapping, der er inkluderet i funktionen pga. relationer til en modeludbyder.
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:
RemoteResourceMappingContext
til rådighed, der kan bruges ved hentning af ressourcegennemløb fra ressourcetilknytninger vha. mappings.
SynchronizationScopeManager
for at tilpasse omfangsstyringen som påkrævet.
De næste to afsnit beskriver disse punkter mere detaljeret.
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.
Klassen SynchronizationScopeManager
kan inddeles i underklasser for at tilpasse omfangsgenerering og styringsprocesser. De to hovedgrunde til at inddele omfangsstyringen i underklasser er:
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.
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.
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.
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.
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:
ModelOperation
stiller en instruktion til rådighed, der anvender de registrerede teamindholdsudbydere til at informere brugeren af en omfangsudvidelse.
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:
ModelSynchronizeParticipant
. ISynchronizePageConfiguration.P_VIEWER_ID
for id'en for fremviseren, der er angivet i forrige trin. MergeActionGroup
til rådighed for at tilpasse udseendet af fletterelaterede funktioner. ModelParticipantMergeOperation
for at behandle transitionen fra en modelbaseret fletning til en fremvisning af resultat i en dialogboks eller oversigten Synkronisér.
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>
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:
RepositoryProvider
, der er knyttet til det projekt, der indeholder ressourcen, til en IHistoryPageSource.
IHistoryPageSource
.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.
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
.