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.