Datalagerkart for integrering av logisk modell

For å gi full støtte til logiske modeller kan en datalagerleverandør utføre følgende:

  1. Bidra med riktige datalageroperasjoner til elementer som tilpasses til ResourceMapping.
  2. Sikre at operasjoner utført på ressurstilordninger inkluderer alle nødvendige modellelementer og ressurser, ved å bruke en ISynchronizationScope og støtte-API.
  3. Tillate modelleverandører å delta i headless-sammenslåing gjennom grensesnittet IMergeContext og støtte-API.
  4. Tillate modelleverandører å delta i sammenslåingsforhåndsvisninger ved hjelp av 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.
  5. Gi tilgang til historikken for arbeidsområdefilene gjennom APIet IFileHistoryProvider.
  6. Gi tilgang til eksterne konfigurasjoner ved hjelp av APIet Eclipse File System API i plugin-modulen org.eclipse.core.filesystem og linke denne til arbeidsområdeprosjekter gjennom ProjectSetCapability.
  7. Støtte dekorasjoner for logiske elementer ved å sørge for en 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.

Bidra med handlinger til ressurstilordninger

API for grunnleggende ressurstilordning

APIet for ressurstilordning består av følgende klasser:

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.

Ressurstilordninger og objektbidrag

Plugin-moduler som bidrar med utvidelser til tilpassbare utvidelsespunkter, må gjøre to endringer for å støtte de nye ResourceMapping-APIene:

  1. Oppdater alle objectContributions for popupMenus-utvidelsespunktene i filen plugin.xml så de rettes mot ResourceMapping i stedet for IResource (der det er relevant).
  2. Oppdater handlingene deres til å virke på 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.

Operasjonsomfang

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:

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 å

  1. besørge en RemoteResourceMappingContext til bruk ved henting av ressurstraverseringer fra ressurstilordninger
  2. overstyre SynchronizationScopeManager og skreddersy omfangsstyringsprosessen etter behov

De neste to seksjonene beskriver disse punktene mer i detalj.

Tilordningskontekst for ekstern ressurs

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.

Subklassifisere SynchronizationScopeManager

Klassen SynchronizationScopeManager kan subklassifiseres for å skreddersy omfangsgenereringen og administrasjonsprosessen. De to hovedgrunnene til å subklassifisere omfangsstyreren er

  1. Datalagerleverandøren må inkludere tilleggsressurser som følge av eventuelle forhold på datalagernivå (f.eks. endringssett). Dette kan gjøres ved å overstyre metoden adjustInputTraversals(ResourceTraversal[]).
  2. Synkroniseringen har en lengre livssyklus (f.eks. Synkroniser-visningen kontra dialogboks) og må ha mulighet til å reagere på omfangsendringene. Grensesnittet 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.

Modellbasert sammenslåing

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:

  1. API for å beskrive synkroniseringsstatus for ressursene som er involvert i sammenslåingen.
  2. API for å gjøre det mulig for modelleverandører å slå sammen modellelementer.
Seksjonene nedenfor beskriver disse to delene.

API for beskrivelse av synkroniseringsstatus

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.

API for modellsammenslåing

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.

Modellinnhold i gruppevisningsprogrammer

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:

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:

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>

Filhistorikk

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:

Funksjonalitet for prosjektsett

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.

Dekorere modellelementer

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.