Teams und verlinkte Ressourcen

Ein Projekt kann Ressourcen enthalten, die sich nicht im Verzeichnis des Projekts im lokalen Dateisystem befinden. Solche Ressourcen werden als verlinkte Ressourcen bezeichnet.

Konsequenzen für Repository-Provider

Verlinkte Ressourcen können für Repository-Provider, die direkt mit dem Dateisystem arbeiten, besondere Probleme darstellen. Dies liegt daran, dass verlinkte Ressourcen naturgemäß nicht in der unmittelbaren Projektverzeichnisstruktur im Dateisystem vorhanden sind.

Bei Providern, die die folgenden Kenndaten aufweisen, sind verlinkte Ressourcen möglicherweise problematisch:

  1. Provider, die ein externes Programm aufrufen, das anschließend direkt mit dem Dateisystem arbeitet.
  2. Provider, die durch "IResource" implementiert sind, jedoch davon ausgehen, dass sich alle Dateien/Ordner eines Projekts als direkt untergeordnete Elemente des Stammverzeichnisses in der jeweiligen Verzeichnisstruktur befinden.

Nehmen wir nun im ersten Fall an, dass der Benutzer eine verlinkte Ressource auswählt und versucht, für die Ressource eine Provideroperation auszuführen. Da der Provider einen Befehlszeilenclient aufruft, kann man davon ausgehen, dass er eine äquivalente Aktion ausführt, um zunächst IResource.getLocation().toOSString() aufzurufen und so die resultierende Dateisystemposition als Argument für das Befehlszeilenprogramm anzugeben. Falls es sich bei der fraglichen Ressource um eine verlinkte Ressource handelt, ergibt sich hierbei eine Datei oder ein Ordner außerhalb der Verzeichnisstruktur für das Projekt. Nicht alle Befehlszeilenclients können einen solchen Fall vorhersehen und verarbeiten. Selbst wenn Ihr Provider die Dateisystemposition einer Ressource abruft, sind für die Verarbeitung von verlinkten Ressourcen wahrscheinlich zusätzliche Schritte erforderlich.

Der zweite Fall ist insofern relativ ähnlich, als hier die implizite Annahme besteht, dass die Struktur der Projektressourcen mit der Struktur der Dateien/Ordner im Dateisystem genau übereinstimmt. Im Allgemeinen könnten für einen Provider Probleme entstehen, wenn eine Mischung von Operationen für "IResource" und "java.io.File" vorliegt. Beispielsweise ist das übergeordnete Element von IFile bei Links nicht mit dem übergeordneten Element von "java.io.File" identisch. Code, der jedoch davon ausgeht, schlägt fehl.

Abwärtskompatibilität

Eine wichtige Vorgabe war, dass die Einführung von verlinkten Ressourcen nicht zu einer versehentlichen Unterbrechung vorhandener Provider führt. Insbesondere galt dies für Provider, die begründetermaßen davon ausgehen, dass die Struktur des lokalen Dateisystem die Projektstruktur widerspiegelt. Infolgedessen können verlinkte Ressourcen standardmäßig nicht zu Projekten hinzugefügt werden, denen ein solcher Provider zugeordnet ist. Außerdem können Projekte, die verlinkte Ressourcen enthalten, standardmäßig nicht über einen solchen Provider gemeinsam benutzt werden.

Strategien für die Verarbeitung von verlinkten Ressourcen

Damit ein Provider Links "toleriert", sollte er die Versionssteuerung von Projekten mit verlinkten Ressourcen zulassen, jedoch die Versionssteuerung der verlinkten Ressourcen selbst inaktivieren können.

Eine erheblich komplexere Lösung würde darin bestehen, die Versionierung der eigentlichen verlinkten Ressourcen zuzulassen. Hiervon wird jedoch abgeraten, da dies zu komplexen Szenarien führt (so könnte beispielsweise eine Datei bereits in einem anderen Projekt der Versionssteuerung durch einen anderen Provider unterliegen). Es empfiehlt sich daher, versionsgesteuerte Projekte zu unterstützen, werden verlinkte Ressourcen nicht versionsgesteuert sind.

Technische Details für Linktolerierung

Implementierungen von Repository-Providern können mit der Unterstützung von verlinkten Ressourcen erweitert werden, indem die Methode RepositoryProvider.canHandleLinkedResources() so überschrieben wird, dass Sie den Wert true zurückgibt. Sobald dies ausgeführt wurde, ist das Vorhandensein von verlinkten Ressourcen in Projekten, die über diesen Repository-Provider gemeinsam benutzt werden, zulässig. Der Repository-Provider muss jedoch Schritte unternehmen, damit sichergestellt ist, dass die verlinkten Ressourcen korrekt verarbeitet werden. Wie bereits erläutert ist es sehr empfehlenswert, dass Repository-Provider alle verlinkten Ressourcen ignorieren. Dies bedeutet, dass verlinkte Ressourcen (und ihre untergeordneten Elemente) von den Aktionen ausgeschlossen werden sollten, die durch den Repository-Provider unterstützt werden. Des Weiteren sollte der Repository-Provider das Standardverhalten zum Versetzen und Löschen bei verlinkten Ressourcen verwenden, falls die Implementierung des Repository-Providers den Standardwert von IMoveDeleteHook überschreibt.

Team-Provider können unter Verwendung von IResource.isLinked() ermitteln, ob eine Ressource ein Link ist. Diese Methode gibt jedoch nur für das Stammverzeichnis eines Links den Wert "true" zurück. Mit dem folgenden Codesegment kann ermittelt werden, ob eine Ressource ein untergeordnetes Element eines Links ist:

String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();

Repository-Provider sollten alle Ressourcen ignorieren, für die der vorstehende Code mit dem Ergebnis true ausgewertet wird.