For å gi full støtte til logiske modeller kan en datalagerleverandør utføre følgende:
ResourceMapping
.ISynchronizationScope
og støtte-API.IMergeContext
og støtte-API.
teamContentProviders
for modellene som er involvert i endringen.
En ModelSynchronizeParticipant
-klasse følger med for å bidra til styringen av forholdet mellom modellinnholdet,
en sammenslåingskontekst og sammenlikningsrammen.
IFileHistoryProvider
.ProjectSetCapability
.
Subscriber
for arbeidsområdet til bruk med APIet
SynchronizationStateTester
.I seksjonene nedenfor beskrives hvert av disse punktene mer i detalj. Plugin-modulen org.eclipse.team.examples.filesystem inneholder et eksempel som illustrerer flere av disse punktene. Du kan hente ut prosjektet fra CVS-datalageret og bruke det som en referanse mens du leser denne opplæringen. Obs: Kildekoden i eksempel-plugin-modulen kan bli endret. Hvis du vil ha en kopi som tilsvarer det som brukes i dette eksempelet, kan du sjekke ut prosjektet med 3.2-versjonskoden (sannsynligvis R3_2) eller med datoen 28. juni 2006.
APIet for ressurstilordning består av følgende klasser:
Object getModelObject()
: Modellobjektet som tilordningen ble avledet (eller tilpasset) på grunnlag av.
ResourceTraversal[]
getTraversals(ResourceMappingContext, IProgressMonitor)
: Ressurstraverseringen som omfatter ressursene som utgjør modellobjektet.
ResourceTraversal
inneholder et sett med ressurser og et dybdeflagg som viser til hvilken dybde
ressurser i traverseringen er knyttet til det opprinnelige modellobjektet.
Ressurstraverseringer gis til en klient ved hjelp av en ressurstilordning for å beskrive innholdet i en modell på en slik måte at
klienten (f.eks. en datalagerleverandør) kan utføre sine operasjoner på en mest mulig effektiv måte.
Følgende metoder er interessante:
getResources()
getDepth()
ResourceMappingContext
og RemoteResourceMappingContext
er litt mer komplisert, og er beskrevet senere.Det er to typer plugin-moduler som kan være interessert i ressurstilordninger: De som besørger en modell som består av, eller er permanent i, ressurser i arbeidsområdet, og de som utfører operasjoner på ressurser. Det første tilfellet vil bli omtalt i modellkartet og de siste i neste seksjon.
Plugin-moduler som bidrar med utvidelser til tilpassbare utvidelsespunkter, må gjøre to endringer for å støtte de nye
ResourceMapping
-APIene:
ResourceMapping
i stedet for IResource
(der det er relevant).
ResourceMapping
i stedet for IResource
og respektere dybdebegrensningene i
traverseringene. Plugin-moduler som legger til objektbidrag til
IResource
, kan nå legge dem til ResourceMapping
i stedet hvis handlingene kan anvendes på flere ressurser.
Her er en XML-snutt som bidrar med en menyhandling til objekter som tilpasses til ressurstilordninger:
<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
vil automatisk gjelde for objekter som tilpasses til
IResource
. Denne transitive tilknytningen håndteres av arbeidsbenken.
Filtrering av bidragene til ressurstilordninger kan utføres ved hjelp av aktiveringsuttrykk.
Et uttrykk for filtrering av prosjektpermanente egenskaper er lagt til for å gjøre det mulig å få
menyene til datalagerleverandører vist på prosjekter som er tilordnet til deres datalagre.
Handlinger som er bidratt til klassen ResourceMapping
, vil bli gitt et valg som inneholder en eller flere
ResourceMappings
.
Det er handlingenes ansvar å oversette ressurstilordningen til et sett med ressurser å operere på.
Dette kan gjøres ved å kalle opp getTraversals
for å hente traverseringene til tilordningen.
Traverseringer brukes for å gjøre det mulig for traverseringenes klienter å optimalisere sine operasjoner på
grunnlag av dybden til ressursene som traverseres.
En klient kan traversere ressursen manuelt eller bruke ressursen og dybden som inndata for en operasjon som handlingen delegerer for å gjøre arbeidet.
Hvis for eksempel en bruker utfører en CVS-oppdatering på en Java-pakke og Java-pakkens ressurstilordning
tilordnes til en mappe med dybde en, vil CVS sende riktig kommando
("cvs update -l" for dem som lurer) for å utføre en grunn oppdatering på mappen som pakken representerer.
Selv om det er mulig å få tak i et sett mer traverseringer direkte fra de valgte ressurstilordningene, finnes det modellforhold (eller datalagerforhold) som kan kreve inkludering av tilleggsressurser eller modellelementer i en operasjon. Neste seksjon beskriver hvordan du sikrer al elle nødvendige ressurser er inkludert i en operasjon.
For gruppeoperasjoner må de valgte tilordningene oversettes til settet med tilordninger som det skal opereres på. Denne prosessen innebærer konsultasjon av alle modelleverandører for å sikre at de blir inkludert i operasjoner på ressurser som samsvarer med deres etableringsregler. Den termen vi bruker for å beskrive hele settet med ressurstilordninger det skal opereres på, er operasjonens omfang. Følgende API er beregnet på dette:
ISynchronizationScope
:
Grensesnitt som definerer API for tilgang til operasjonens omfang.
Det gir tilgang til alle ressurstilordningene som det opereres på, og traverseringene for disse tilordningene slik de ble beregnet
under omfangsbyggingsprosessen.
ISynchronizationScopeManager
:
Grensesnitt som definerer API for å opprette og styre et omfang. SynchronizationScopeManager
:
Utvidbar klasse som sørger for standard implementering av APIet ISynchronizationScopeManager
.ModelOperation
:
Utvidbar operasjonsklasse som genererer et omfang ved hjelp av medfølgende omfangsstyrer og
gir beskjed om ytterligere ressurser eller tilordninger er inkludert i operasjonen på grunn av modelleverandørforhold.
Metoden initialize(IProgressMonitor) for klassen
SynchronizationScopeManager
håndterer hele prosessen med å konvertere en inndatasett for ressurstilordninger
til hele settet med tilordninger som det må opereres på, samt hele settet med traverseringer som omfatter disse tilordningene.
En datalagerleverandør kan skreddersy prosessen ved å
RemoteResourceMappingContext
til bruk ved henting av ressurstraverseringer fra ressurstilordninger
SynchronizationScopeManager
og skreddersy omfangsstyringsprosessen etter behov
De neste to seksjonene beskriver disse punktene mer i detalj.
For å sikre at alle nødvendige ressurser blir inkludert i en gruppeoperasjon kan modelleverandøren trenge evnen til å se på status for en eller flere ressurser i datalageret. For noen modeller er ikke dette nødvendig. For eksempel er en Java-pakke en container som besøkes til dybde en, uansett modellens fjernstarting. gitt dette kan en datalagerleverandør lett bestemme at utgående slettinger skal inkluderes ved iverksetting, eller at innkommende tilføyelser skal inkluderes ved oppdatering. Ressursene som utgjør enkelte logiske modeller, kan imidlertid endres over tid. For eksempel kan ressursene som utgjør et modellelement, avhenge av innholdet i en manifestfil (eller en annen lignende mekanisme). For at ressurstilordningen skal returnere riktig traversering, må den få tilgang til det eksterne innholdet i manifestfilen (hvis det er forskjellig fra det lokale innholdet) så den kan se om det finnes ytterligere ressurser som må inkluderes. Det er ikke sikkert at disse tilleggsressursene finnes i arbeidsområdet, men datalagerleverandøren vil vite hvordan den skal kontrollere om de gjorde det da den valgte handlingen ble utført.
For å støtte mer komplekse modeller kan en RemoteResourceMappingContext
sendes til metoden ResourceMapping#getTraversals
.
Når det gis en kontekst, kan tilordningen bruke den for å sikre at alle nødvendige ressurser inkluderes i traverseringen.
Hvis det ikke gis en kontekst,
kan tilordningen anta at bare den lokale statusen er av interesse.
Tilordningskonteksten for den eksterne ressursen har tre grunnleggende spørringer:
Svaret på det første spørsmålet over avhenger av typen operasjon som utføres. Det typiske er at oppdateringer og sammenslåinger er treveis, mens sammenlikninger og erstatningsoperasjoner (ihvertfall for CVS) er toveis.
APIet Eclipse Team API inkluderer en Subscriber
-klasse som definerer et API for overføring av
synkroniseringsstatus mellom det lokale arbeidsområdet og en ekstern server.
Det finnes en SubscriberResourceMappingContext
som bruker en Subscriber
til å få tilgang til den nødvendige eksterne status.
Klienter som har en Subscriber
, behøver ikke å gjøre noe mer for å få tak i en
ressurstilordningskontekst.
Klassen SynchronizationScopeManager
kan subklassifiseres for å skreddersy omfangsgenereringen og
administrasjonsprosessen.
De to hovedgrunnene til å subklassifisere omfangsstyreren er
ISynchronizationScopeParticipant
definerer APIet som modelleverandører kan bruke for å delta i omfangsstyringsprosessen.
Klassen SubscriberScopeManager
er den Subscriber
-basert subklasse under
SynchronizationScopeManager
som involverer deltakere i omfangsstyringsprosessen.
Et eksempel på hvorfor denne typen prosess er nødvendig, er arbeidssett.
Hvis et arbeidssett er en av ressurstilordningene i et omfang, vil settet med traverseringer som omfattes av omfanget,
øke dersom ressurser er lagt til arbeidssettet.
Den viktigste typen datalageroperasjon som krever modelldeltakelse, er sammenslåing.
I mange tilfeller behøver modellene bare å delta på filnivå.
For dette ble APIet IStorageMerger
innført for å gjøre det mulig for modelleverandører å bidra med sammenslåinger
som skal brukes til å slå sammen filer med en bestemt tiltype eller innholdstype.
I noen tilfeller kan imidlertid modellene trenge ytterligere kontekst for å delta ordentlig i en sammenslåing.
dette formål har vi innført APIene IResourceMappingMerger
og IMergeContext
.
Sammenslåingsoperasjoner utløses fortsatt av handlinger knyttet til en datalagerleverandør. Straks brukeren ber om en sammenslåingsoperasjon, må imidlertid datalagerleverandøren involvere modelleverandørene i sammenslåingsprosessen for å sikre at sammenslåingen ikke ødelegger modellen på noen måte.
Det er to hoveddeler av APIet for datalagerleverandør knyttet til modellbasert sammenslåingsstøtte:
Et viktig aspekt ved modellbasert sammenslåing er APIet som brukes for å kommunisere synkroniseringsstatusen til ressursene som er involvert, til modelleverandøren. Følgende grensesnitt brukes for å beskrive synkroniseringsstatus:
Abstrakte klasser finnes for alle disse grensesnittene sammen med konvensjonen som klassenavnene om at klassenavnene samsvarer med
grensesnittnavnene med "I"-prefikset fjernet. Den eneste klassen som datalagerleverandører må overstyre, er
klassen ResourceDiff
, slik at relevante før- og etter-filrevisjoner kan besørges.
Grensesnittet IMergeContext utvider synkroniseringskonteksten med flere metoder som støtter sammenslåing. Det finnes tilbakekallingsmetoder for å
Det finnes en abstrakt MergeContext-klasse som inneholder standardimplementeringer for mye av sammenslåingsvirkemåten og bruker IStorageMerger for å utføre treveis sammenslåinger. Det finnes også en SubscriberMergeContext-klasse som håndterer datautfylling og vedlikehold av synkroniseringsstatusbeskrivelsen knyttet til sammenslåingskonteksten.
Det finnes en operasjonsklasse,
ModelMergeOperation, som bruker APIet
IResourceMappingMerger
til å utføre en modellbasert sammenslåingsoperasjon.
Subklasser må overstyre metoden initializeContext(IProgressMonitor)
for å returnere en sammenslåingskontekst. Operasjonen bruker denne kontekst for å forsøke en
modellbasert headless-sammenslåing. Hvis det oppstår konflikter, overlates forhåndsvisningen
til subklassen. Som vi skal se i neste seksjon, er det en
ModelParticipantMergeOperation
som gir mulighet for forhåndsvisning ved hjelp av en
ModelSynchronizeParticipant.
Støtte for visning av logiske modeller i en gruppeoperasjon besørges ved hjelp av
den Felles navigator-rammen som ble introdusert i Eclipse 3.2. Logiske modeller kan knytte en innholdsutvidelse til en modelleverandør
ved hjelp av utvidelsespunktet org.eclipse.team.ui.teamContentProvider.
Gruppeleverandørene får tilgang til disse innholdsleverandørene gjennom ITeamContentProviderManager
.
Det er flere steder der en gruppeleverandør kan ønske å vise logiske modeller:
ModelOperation
har en klarmelding som bruker
den registrerte gruppens innholdsleverandører til å informere brukeren om en omfangsutvidelse.
ModelSynchronizeParticipant
besørger integrering til Synkroniser-visningen eller en annen container som kan vise
iSynchronizePages
.
Deltakeren bruker både den
eksisterende synkroniseringsdeltakelsesfunksjonaliteten og Felles navigator-funksjonaliteten
for å gjøre det mulig for gruppeleverandører og modeller å skreddersy verktøylinjen, hurtigmenyen og andre aspekter av
forhåndsvisningen av sammenslåing.
ModelSynchronizeParticipant
besørger følgende:
Her er en huskeliste med trinn for å skreddersy en modellsynkroniseringsdeltaker for en bestemt gruppeleverandør:
ModelSynchronizeParticipant
ISynchronizePageConfiguration.P_VIEWER_ID
til IDen for visningsprogrammet som ble oppgitt i forrige trinn.
MergeActionGroup
for å skreddersy utseendet til sammenslåingsrelaterte handlinger.
ModelParticipantMergeOperation
for å håndtere overgangen fra en modellbasert sammenslåing til en
forhåndsvisning i en Synkroniser-visning.
Følgende XML-snutter illustrerer hvordan CVS-deltakelsesklassen er registrert, og hvordan dens visningsprogram er definert:
<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 API for filhistorikk er lagt til for å gjøre det mulig for modeller å få tilgang til filers historikk. Filhistorikk-APIet består av følgende grensesnitt:
Sammen med dette APIet er det lagt til en historikkvisning for generisk fil. Dette vil gjøre det mulig for gruppeleverandører å vise sin fil-/ressurshistorikk i en delt visning, og gjør det også mulig for modeller å vise modellelementhistorikken for elementer som ikke tilordnes direkte til filer. Historikkvisningen er en sidebasert visning som henter en side for det valgte elementet på følgende måte:
RepositoryProvider
knyttet til prosjektet som inneholder ressursen, til en
IHistoryPageSource.
IHistoryPageSource
.Det er lagt til metoder til
ProjectSetCapability
for å støtte oversettelse mellom
en referansestreng som brukes til å identifisere en tilordning mellom et prosjekt og eksternt innhold og URIer som identifiserer et filsystemskjema
registrert med utvidelsespunktet
org.eclipse.core.filesystem.filesystems.
Gruppeleverandører kan eventuelt gi støtte for dette, slik at
logiske modeller kan utføre ekstern blaing og prosjektlasting.
Gruppeleverandører kan dekorere modellelementer ved å konvertere deres forenklede dekorasjoner til å virke for ressurstilordninger på samme måte som objektbidrag konverteres til å virke for ressurstilordninger. Det er imidlertid ett aspekt ved dekorasjoner for logiske modellelementer som er problematisk. Hvis et modellelement ikke har en en til en-tilordning til en ressurs, kan ikke modellelementet motta en etikettoppdatering når de underliggende ressursene endres.
For å løse dette problemet ble
ITeamStateProvider
innført
og gav modelleverandørene tilgang til statusendringer som kan påvirke gruppedekorasjonene.
Dessuten kan modellvisninger bruke en
SynchronizationStateTester
til å bestemme når
etikettene til logiske modellelementer må oppdateres.
Dette APIet er avhengig av grensesnittet ITeamStateProvider
for å avgjøre når
gruppestatusen til en ressurs er endret og kan sendes til en gruppedekoratør som del av en
IDecorationContext
.