Depois de criar um RepositoryProvider,
há outros mecanismos de gerenciamento de recursos que devem ser
entendidos:
Em vários casos, pode ser necessário manter certos arquivos sob controle do repositório. Por exemplo, os recursos que são derivados de recursos existentes podem normalmente ser omitidos do repositório. Por exemplo, os arquivos de origem compilados, (como arquivos Java ".class"), podem ser omitidos desde que seu arquivo de origem correspondente (".java") esteja no repositório. Também pode não ser apropriado controlar a versão de arquivos de metadados que são gerados pelos fornecedores de repositório. O ponto de extensão org.eclipse.team.core.ignore permite que os fornecedores declarem tipos de arquivos que devem ser ignorados para operações do fornecedor de repositório. Por exemplo, o cliente CVS declara o seguinte:
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
A marcação simplesmente declara um nome de arquivo pattern que deve ser ignorado e um atributo selected que declara o valor de seleção padrão do tipo de arquivo no diálogo de preferências. Basicamente, fica a cargo do usuário decidir quais arquivos devem ser ignorados. O usuário pode selecionar, desmarcar, incluir ou excluir tipos de arquivos da lista padrão de arquivos ignorados.
Alguns repositórios implementam tratamento diferente para arquivos de texto versus binários. A extensão org.eclipse.team.core.fileTypes permite que os plug-ins declarem tipos de arquivos como arquivos de texto ou binários. Por exemplo, as ferramentas Java declaram o seguinte:
<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>
A marcação permite que os plug-ins definam um tipo de arquivo pela extensão e atribuam um tipo texto ou binário. Como no caso dos arquivos ignorados, fica a cargo do usuário gerenciar a lista de tipos de arquivos de texto e binários.
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.
Os recursos vinculados podem trazer desafios específicos para fornecedores 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 fornecedores que possuem as características a seguir podem ser afetadas pelos recursos vinculados:
No primeiro caso, vamos assumir que o usuário obtém um recurso vinculado e tenta executar uma operação do fornecedor nele. Como o fornecedor chama um cliente de linha de comandos, podemos assumir que o fornecedor 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 fornecedor 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 fornecedor 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.
Era importante que a introdução de recursos vinculados não fizesse os provedores existentes falharem inadvertidamente. Especificamente, a preocupação era para fornecedores 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 fornecedor. Além disso, os projetos que contêm recursos vinculados não podem ser compartilhados por padrão com esse fornecedor.
Para ser "propício a link", um fornecedor deve permitir que os projetos com recursos vinculados tenham a versão controlada, mas pode não permitir o controle de 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 fornecedor). Sendo assim, nossa recomendação é suportar projetos com versão controlada que contêm recursos vinculados com versão não-controlada.
Pode ser feito upgrade das implementações do fornecedor 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 fornecedor de repositório. Entretanto, o fornecedor de repositório deve executar etapas para assegurar que os recursos vinculados são tratados adequadamente. Como mencionado anteriormente, é altamente sugerido que os fornecedores 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 fornecedor de repositório. Além disso, o fornecedor de repositório deve utilizar o comportamento padrão de movimentação e exclusão para recursos vinculados se a implementação do fornecedor de repositório substituir o IMoveDeleteHook padrão.
Os fornecedores 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 fornecedores de repositório devem ignorar qualquer recurso para o qual o código acima for avaliado como true.
É comum que as implementações de repositório utilizem arquivos e pastas extras para armazenar informações específicas sobre a implementação do repositório. Embora esses arquivos possam ser necessários no espaço de trabalho, não servem para outros plug-ins ou para o usuário final.
Os fornecedores de equipe podem utilizar IResource.setTeamPrivateMember(boolean) para indicar que um recurso é particular na implementação de um fornecedor de equipe. Os recursos recém-criados não são membros particulares por padrão, portanto, esse método deve ser utilizado para marcar explicitamente o recurso como particular da equipe. Um uso comum é marcar uma subpasta do projeto como particular da equipe quando o projeto é configurado para a equipe e a subpasta é criada.
Outra API de recurso que enumera recursos (como árvores de deltas de recursos) excluirá membros particulares da equipe, a menos que solicitada explicitamente para incluí-los. Isso significa que a maioria dos clientes não "verá" os recursos particulares da equipe e eles não serão mostrados para o usuário. O navegador de recursos não mostra os membros particulares da equipe por padrão, mas os usuários podem indicar por meio de Preferências que gostariam de ver os recursos particulares da equipe.
Tentativas de marcar projetos ou a raiz da área de trabalho como particulares da equipe serão ignoradas.
Como os recursos de um projeto sob controle de versão são mantidos no repositório, é possível compartilhar projetos com membros de equipes compartilhando-se uma referência às informações específicas do repositório necessárias para reconstruir um projeto no espaço de trabalho. Isso é feito através de um tipo especial de exportação de arquivos para os conjuntos de projetos de equipe.
No 3.0, a API foi incluída em ProjectSetCapability para permitir que os fornecedores do repositório declarem uma classe que implemente o salvamento do projeto para projetos sob seu controle. Quando o usuário escolhe exportar conjuntos de projetos, apenas os projetos configurados com repositórios que definem conjuntos de projetos são mostrados como candidatos para exportação. Esta API substitui a API de serialização do projeto antigo (consulte a seguir).
A classe do recurso do conjunto de projeto para um fornecedor de repositório é obtida a partir da classe RepositoryProviderType que é registrada na mesma extensão do fornecedor do repositório. Exemplo:
<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>
Antes do 3.0, o ponto de extensão org.eclipse.team.core.projectSets permitia que os fornecedores de repositório declarassem uma classe que implementa o salvamento do projeto para os projetos sob seu controle. Quando o usuário escolhe exportar conjuntos de projetos, apenas os projetos configurados com repositórios que definem conjuntos de projetos são mostrados como candidatos para exportação.
Por exemplo, o cliente CVS declara o seguinte:
<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>
A classe especificada deve implementar IProjectSetSerializer. A utilização dessa interface ainda é suportada no 3.0, mas foi reprovada.