Når du har opprettet en RepositoryProvider,
finnes det andre ressursstyringsmekanismer som du må gjøre deg kjent med:
Av og til er det unødvendig med datalagerkontroll på bestemte filer. For eksempel er ressurser som er avledet fra eksisterende ressurser, oftest utelatt fra datalageret. Som et eksempel kan kompilerte kildefiler (som Java-filene ".class") utelates siden den tilhørende kildenfilen (".java") er i datalageret. Det kan også være uheldig å bruke versjonskontroll på datafiler som genereres av datalagerleverandører. Med utvidelsespunktet org.eclipse.team.core.ignore kan leverandører deklarere filtyper som skal ignoreres ved operasjoner for datalagerleverandør. For eksempel deklarerer CVS-klienten følgende:
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
Kodetypen deklarerer ganske enkelt et filnavnmønster (pattern) som skal ignoreres, og en valgt (selected) attributt som deklarerer standardvalgverdien for filtypen i preferansedialogboksen. Det er opp til brukeren å bestemme hvilke filer som skal ignoreres. Brukeren kan velge, oppheve valg av, legge til eller slette filtyper fra standardlisten over ignorerte filer.
Noen datalagre implementerer ulik behandling av tekstfiler kontra binærfiler. Utvidelsen org.eclipse.team.core.fileTypes gjør det mulig for plugin-moduler å deklarere filtyper som tekst- eller binærfiler. For eksempel deklarerer Java-verktøyene følgende:
<extension point="org.eclipse.team.core.fileTypes">
<fileTypes extension="java" type="text"/>
<fileTypes extension="classpath" type="text"/>
<fileTypes extension="properties" type="text"/>
<fileTypes extension="class" type="binary"/>
<fileTypes extension="jar" type="binary"/>
<fileTypes extension="zip" type="binary"/>
</extension>
Med denne kodetypen kan plugin-moduler definere en filtype gjennom en utvidelse (extension) og tilordne en type som tekst eller binær. På samme måte som med ignorerte filer, er det opp til brukeren å styre listen over tekst og binære filtyper.
Et prosjekt kan inneholde ressurser som ikke er plassert i prosjektkatalogen på det lokale filsystemet. Slike ressurser kalles linkede ressurser.
Linkede ressurser kan by på spesielle utfordringer for datalagerleverandører som kjøres direkte mot filsystemet. Dette skyldes at linkede ressurser ikke er utformet til å ligge direkte under prosjektkatalogtreet i filsystemet.
Leverandører med følgende egenskaper kan bli påvirket av linkede ressurser:
I det første tilfellet forutsetter vi at brukeren velger en linket ressurs, og forsøker å utføre en leverandøroperasjon i ressursen. Siden leverandøren kaller en kommandolinjeklient, antar vi at leverandøren utfører noe som motsvarer å først kalle IResource.getLocation().toOSString(), og angir filsystemplasseringen som oppstår som et argument for kommandolinjeprogrammet. Hvis den aktuelle ressursen er en linket ressurs, oppstår en fil/mappe utenfor prosjektets katalogtre. Ikke alle kommandolinjeklienter kan forvente og har muligheten til å håndtere dette. Vi kan sammenfatte dette med å si at hvis leverandøren får en filsystemplassering for en ressurs, vil dette sannsynligvis medføre ekstraarbeid ved håndtering av linkede ressurser.
Det andre tilfellet er nokså likt det første fordi det er underforstått at strukturen i prosjektets ressurser, er i samsvar med strukturen i filene og mappen i filsystemet. Det kan oppstå problemer for leverandøren hvis operasjonene IResource og java.io.File blandes. For linker er for eksempel det overordnede objektet for IFile ikke det samme som overordnet objekt for java.io.File. Kode som forventer at dette er det samme, vil mislykkes.
Det har vært viktig at introduksjonen av linkede ressurser ikke ved en feiltakelse skulle ødelegge eksisterende leverandører. Spesielt var man bekymret for leverandører som naturlig nok antok at den lokale filsystemstrukturen gjenspeilte prosjektstrukturen. Som en følge av dette, kan ikke linkede ressurser legges til i prosjekter som er tilordnet en slik leverandør. Dessuten kan som standard ikke prosjekter som inneholder linkede ressurser, deles med den leverandøren.
For å være "linkvennlig" må en leverandør tillate at det utføres versjonskontroll i prosjekter med linkede ressurser, men kan nekte versjonskontroll av selve de linkede ressursene.
En langt mer kompleks løsning er å tillate versjonsbehandling av de faktiske linkede ressursene, men vi anbefaler ikke dette fordi det medfører komplekse scenarier (det kan for eksempel hende at filen allerede er versjonskontrollert i et annet prosjekttre av en annen leverandør). Vi anbefaler derfor heller å støtte versjonskontrollerte prosjekter som inneholder ikke-versjonskontrollerte linkede ressurser.
Implementeringer av datalagerleverandører kan oppgraderes for å støtte linkede ressurser ved å overstyre RepositoryProvider.canHandleLinkedResources()-metoden slik at den returnerer true. Når dette er gjort, er det tillatt med linkede ressurser i prosjekter som deles med den datalagerleverandøren. Datalagerleverandøren må imidlertid aktivt sikre at linkede ressurser blir håndtert på riktig måte. Som vi allerede har nevnt, anbefaler vi på det sterkeste at datalagerleverandører ignorerer alle linkede ressurser. Dette betyr at linkede ressurser (med underordnede objekter) bør utelates fra handlingene som støttes av datalagerleverandøren. Datalagerleverandøren bør videre bruke standardfunksjonalitet for flytting og sletting av linkede ressurser hvis implementeringen av datalagerleverandøren overstyrer standard IMoveDeleteHook.
Gruppeleverandører kan bruke IResource.isLinked() til å finne ut om en ressurs er en link. Denne metoden returnerer imidlertid bare "true" for roten til en link. Følgende kodesegment kan brukes til å finne ut om en ressurs er underordnet en link.
String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();
Datalagerleverandører bør ignorere ressurser som returneres som true av koden ovenfor.
Ved implementeringer av datalagre brukes vanligvis ekstra filer og mapper for å lagre informasjon som er spesifikk for denne implementeringen. Selv om disse filene behøves i arbeidsområdet, er de ikke av interesse for andre plugin-moduler eller for sluttbrukeren.
Gruppeleverandører kan bruke IResource.setTeamPrivateMember(boolean) for å angi at en ressurs er spesifikk for implementeringen av en gruppeleverandør. Nyopprettede ressurser er som standard ikke spesifikke medlemmer, og derfor må metoden brukes eksplisitt for å merke ressursen som gruppespesifikk. Det er vanlig å merke en undermappe for prosjektet som gruppespesifikk når prosjektet er konfigurert for gruppe og undermappen opprettes.
Andre ressursprogrammeringsgrensesnitt som oppgir ressurser (for eksempel ressursdeltatrær) utelater gruppespesifikke medlemmer med mindre det eksplisitt kommer en forespørsel om å inkludere dem. Dette betyr at de fleste klientene ikke "ser" de gruppespesifikke ressursene, og at de ikke blir vist til brukeren. Ressursnavigatoren viser som standard ikke gruppespesifikke medlemmer, men brukere kan via Preferanser angi at de vil se gruppespesifikke ressurser.
Forsøk på å merke prosjekter eller arbeidsområderoten som gruppespesifikk, ignoreres.
Siden ressursene i et prosjekt under versjonskontroll oppbevares i datalageret, er det mulig å dele prosjekter med gruppemedlemmer ved å dele en referanse til den datalagerspesifikke informasjonen som trengs for å rekonstruere et prosjekt i arbeidsområdet. Dette gjøres ved hjelp av en spesiell fileksporttype for gruppeprosjektsett.
I versjon 3.0 er programmeringsgrensesnitt lagt til i ProjectSetCapability slik at datalagerleverandører kan deklarere en klasse som implementerer prosjektlagring for prosjekter de håndterer. Når brukeren velger å eksportere prosjektsett, er det bare prosjekter som er konfigurert med datalagre som definerer prosjektsett, som vises som kandidater for eksport. Dette programmeringsgrensesnittet erstatter gamle grensesnittet for serialisering av prosjektsett (se nedenfor).
Funksjonsklassen for prosjektsett for en datalagerleverandør hentes fra RepositoryProviderType-klassen, som registreres i den samme utvidelsen som datalagerleverandøren. Eksempel:
<extension point="org.eclipse.team.core.repository">
<repository
typeClass="org.eclipse.team.internal.ccvs.core.CVSTeamProviderType"
class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider"
id="org.eclipse.team.cvs.core.cvsnature">
</repository>
</extension>
Før versjon 3.0, ble utvidelsespunktet org.eclipse.team.core.projectSets brukt til å angi at datalagerleverandører kunne deklarere en klasse som implementerer prosjektlagring for prosjekter som de håndterer. Når brukeren velger å eksportere prosjektsett, er det bare prosjekter som er konfigurert med datalagre som definerer prosjektsett, som vises som kandidater for eksport.
For eksempel deklarerer CVS-klienten følgende:
<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>
Den oppgitte klassen må implementere IProjectSetSerializer. Det er fortsatt støtte for bruk av dette grensesnittet i versjon 3.0, men det er foreldet.