Recursos Vinculados e de Equipe

Um projeto pode conter recursos que não estão localizados no diretório do projeto no sistema de arquivos local. Esses recursos são referidos como recursos vinculados.

Conseqüências para Provedores de Repositório

Os recursos vinculados podem trazer desafios específicos para provedores de repositório que operam diretamente no sistema de arquivos. Isso é uma conseqüência do fato que os recursos vinculados por design não existem na árvore de diretórios imediata do projeto no sistema de arquivos.

Os provedores que possuem as características a seguir podem ser afetadas pelos recursos vinculados:

  1. Aqueles que fizerem chamadas a um programa externo que, então, opera diretamente no sistema de arquivos.
  2. Aqueles que são implementados nos termos do IResource mas assumem que todos os arquivos/pastas em um projeto existem como descendentes diretos dessa árvore de diretórios com raiz única.

No primeiro caso, vamos assumir que o usuário obtém um recurso vinculado e tenta executar uma operação do provedor nele. Como o provedor chama um cliente de linha de comandos, podemos assumir que o provedor faz algo equivalente a chamar primeiramente IResource.getLocation().toOSString(), alimentando a localização do sistema de arquivos resultante como um argumento para o programa da linha de comandos. Se o recurso em questão for um recurso vinculado, isso produzirá um arquivo/pasta fora da árvore de diretórios do projeto. Nem todos os clientes da linha de comando podem esperar e serem capazes de tratar esse caso. Resumindo, se o provedor sempre obter a localização do sistema de arquivos de um recurso, ele também necessitará de trabalho adicional para tratar recursos vinculados.

O segundo caso é bastante semelhante, visto que existe uma suposição implícita de que a estrutura dos recursos do projeto é 1:1 com aquela dos arquivos/pastas do sistema de arquivos. Em geral, um provedor poderia estar com problemas se ele misturar operações IResource e java.io.File. Por exemplo, no caso de links, o pai de IFile não é o mesmo que o pai de java.io.File e o código que assumir que eles são os mesmos irá falhar.

Compatibilidade Retroativa

Era importante que a introdução de recursos vinculados não fizesse os provedores existentes falharem inadvertidamente. Especificamente, a preocupação era para provedores que assumiam razoavelmente que a estrutura do sistema de arquivos local espelhava a estrutura do projeto. Conseqüentemente, por padrão os recursos vinculados não podem ser adicionados a projetos que estão mapeados a tal provedor. Além disso, os projetos que contêm recursos vinculados não podem ser compartilhados por padrão com esse provedor.

Estratégias para Tratar Recursos Vinculados

Para que um provedor seja "propício a link", ele deve permitir que os projetos com recursos vinculados tenham sua versão controlada, mas pode recusar o controle da versão dos próprios recursos vinculados.

Uma solução consideravelmente mais complexa seria permitir a criação de versão dos recursos vinculados reais, mas isso deveria ser desencorajado pois traz com ela cenários complexos (por exemplo, o arquivo já pode ter sua versão controlada sob uma árvore de projetos diferente por outro provedor). Sendo assim, nossa recomendação é suportar projetos com versão controlada que contêm recursos vinculados com versão não-controlada.

Detalhes Técnicos para Ser "Propício a Link"

Pode ser feito upgrade das implementações do provedor de repositório para suportar recursos vinculados pela substituição do método RepositoryProvider.canHandleLinkedResources() para retornar true. Uma vez feito isso, a existência dos recursos vinculados será permitida em projetos compartilhados com esse provedor de repositório. Entretanto, o provedor de repositório deve executar etapas para assegurar que os recursos vinculados são tratados adequadamente. Como mencionado anteriormente, é altamente sugerido que os provedores de repositório ignorem todos os recursos vinculados. Isso significa que os recursos vinculados (e seus filhos) devem ser excluídos das ações suportadas pelo provedor de repositório. Além disso, o provedor de repositório deve utilizar o comportamento padrão de movimentação e exclusão para recursos vinculados se a implementação do provedor de repositório substituir o IMoveDeleteHook padrão.

Os provedores de equipe podem utilizar IResource.isLinked() para determinar se um recurso é um link. Entretanto, esse método retorna true apenas para a raiz de um link. O segmento de código a seguir pode ser utilizado para determinar se um recurso é filho de um link.

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

Os provedores de repositório devem ignorar qualquer recurso para o qual o código acima for avaliado como true.

Copyright IBM Corporation e outros 2000, 2003.