Um projecto poderá conter recursos que não se encontrem no directório do projecto no sistema de ficheiros local. Estes recursos chamam-se recursos ligados .
Os recursos ligados podem constituir verdadeiros desafios para fornecedores de repositórios que funcionem directamente no sistema de ficheiros. Trata-se de uma consequência do facto de os recursos ligados por concepção não existirem na árvore de directórios do projecto imediato no sistema de ficheiros.
Os fornecedores que mostrem as seguintes características poderão ser afectados por recursos ligados:
No primeiro caso, suponhamos que o utilizador pega num recurso ligado e tenta executar uma operação de fornecedor nele. Dado que o fornecedor chama um cliente de linha de comandos, podemos supor que o fornecedor realiza algo equivalente a chamar primeiro IResource.getLocation().toOSString(), inserindo a localização do sistema de ficheiros resultante como argumento para o programa de linha de comandos. Se o recurso em questão for um recurso ligado, irá resultar num ficheiro/pasta fora da árvore de directórios do projecto. Não se pode esperar que todos os clientes de linha de comandos podem tratar deste caso. Em suma, se o fornecedor obtiver a localização no sistema de ficheiros de um recurso, irá precisar de mais trabalho para tratar recursos ligados.
O segundo caso é muito semelhante no sentido em que se supõe implicitamente que a estrutura dos recursos do projecto é 1:1 com a dos ficheiros/pastas do sistema de ficheiros. Regra geral, um fornecedor poderá ter problemas se misturar operações IResource e java.io.File. Por exemplo, no caso de ligações, o ascendente de IFile não é o mesmo que o ascendente de java.io.File, pelo que o código que parta desta suposição irá falhar.
Era importante que a introdução de recursos ligados não danificasse inadvertidamente os fornecedores existentes. Mais especificamente, a preocupação incidia em fornecedores que supusessem razoavelmente que a estrutura do sistema de ficheiros local reflectia a estrutura do projecto. Por conseguinte, e por predefinição, os recursos ligados não podem ser adicionados a projectos que estejam correlacionados com tal fornecedor. Além disso, os projectos que contenham recursos ligados não podem, por predefinição, ser partilhados com esse fornecedor.
Para poder ser compatível com ligações, um fornecedor deve permitir que projectos com recursos ligados tenham as respectivas versões controladas, mas poder desautorizar o controlo de versões dos recursos ligados propriamente ditos.
Um solução muito mais complexa seria permitir o versionamento dos recursos ligados propriamente ditos, mas isto deve ser desencorajado dado que acarreta cenários complexos (p.ex., o ficheiro poderá já ter controlo de versões numa árvore de projectos diferente e por outro fornecedor). Por conseguinte, a nossa recomendação incide em suportar projectos sob controlo de versões que contenham recursos ligados livres de controlo de versões.
As implementações de fornecedores de repositórios podem ser actualizadas para suportar recursos ligados mediante sobreposição do método RepositoryProvider.canHandleLinkedResources() para devolver true. Uma vez feito isto, os recursos ligados poderão existir em projectos partilhados com esse fornecedor de repositórios. Todavia, o fornecedor de repositórios deve tomar medidas para garantir o tratamento correcto dos recursos ligados. Tal como mencionámos em cima, sugerimos fortemente que os fornecedores de repositórios ignorem todos os recursos ligados. Significa isto que os recursos ligados (e seus descendentes) devem ser excluídos das acções suportadas pelo fornecedor de repositórios. Mais, o fornecedor de repositórios deve utilizar o comportamento predefinido de mover e eliminar para recursos ligados, se a implementação do fornecedor de repositórios se sobrepuser ao IMoveDeleteHook predefinido.
Os fornecedores de equipa podem utilizar um IResource.isLinked() para determinar se um recurso é ou não uma ligação. No entanto, este método só devolve verdadeiro (true) relativamente à raiz de uma ligação. Pode utilizar-se o segmento de código seguinte para determinar se um recurso é descendente de uma ligação.
String linkedParentName = resource.getProjectRelativePath().segment(0);IFolder linkedParent = resource.getProject().getFolder(linkedParentName);boolean isLinked = linkedParent.isLinked();
Os fornecedores de repositórios devem ignorar recursos relativamente aos quais o código supra devolver true.