Une fois que vous avez créé RepositoryProvider, il y a un autre mécanisme de gestion des ressources à connaître :
Dans plusieurs cas, il peut s'avérer inutile de conserver certains fichiers sous le contrôle du référentiel. Par exemple, les ressources dérivées des ressources existantes peuvent souvent être omises du référentiel. Par exemple, les fichiers source compilés (fichiers ".class" Java, par exemple) peuvent être omis car le fichier source correspondant (".java") se trouve dans le référentiel. Il peut également être inapproprié de contrôler la version des fichiers de métadonnées qui sont générés par les fournisseurs de référentiel. Le point d'extension org.eclipse.team.core.ignore permet aux fournisseurs de déclarer des types de fichier qui doivent être ignorés pour les opérations liées au fournisseur de référentiel. Par exemple, le client CVS effectue la déclaration suivante :
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
Les marques déclarent simplement un modèle de nom de fichier devant être ignoré et un attribut sélectionné déclarant la valeur de sélection par défaut du type de fichier dans la boîte de dialogue de préférences. Il revient à l'utilisateur de décider si les fichiers doivent finalement être ignorés. L'utilisateur peut sélectionner, désélectionner, ajouter ou supprimer des types de fichiers de la liste par défaut de fichiers ignorés.
Certains référentiels implémentent un traitement différent pour ces deux types de fichiers. L'extension org.eclipse.team.core.fileTypes permet aux plug-in de déclarer des types de fichiers en tant que texte ou binaires. Par exemple, les outils Java déclarent ce qui suit :
<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>
Les marques permettent au plug-in de définir le type par extension et d'assigner le type texte ou binaire. Comme pour les fichiers ignorés, il revient finalement à l'utilisateur de gérer la liste de types de fichiers texte ou binaires.
Un projet peur contenir des ressources ne se trouvant pas dans son répertoire du système de fichiers local. Ces ressources sont alors qualifiées de liées.
Les ressources liées peuvent s'avérer problématiques pour les fournisseurs de référentiels fonctionnant directement par rapport au système de fichiers. En effet, les ressources liées n'existent pas par nature dans l'arborescence du projet.
Les fournisseurs présnetant les caractéristiques ci-après peuvent rencontrer des problèmes dans le cas de ressources liées :
Dans le premier cas, imaginons que l'utilisateur choisit une ressource liée et tente d'effectuer une opération de fournisseur. Sachant que le fournisseur appelle un client de ligne de commande, nous pouvons comparer cette opération au premier appel de IResource.getLocation().toOSString(), ce qui fait de l'emplacement dans le système de fichier un argument pour le programme de ligne de commande. Si la ressource en question est liée, un fichier/dossier est créé en dehors de l'arborescence du projet. Tous les clients de ligne de commande ne peuvent anticiper et gérer ce cas de figure. En bref, si votre fournisseur obtient l'emplacement d'une ressource dans le système de fichiers, un travail supplémentaire sera requis pour gérer les ressources liées.
Le second cas est assez semblable vu que la structure des ressources est implicitement supposée être 1:1 par rapport aux fichiers/dossiers du système de fichiers. En général, un fournisseur peut connaître des difficultés s'il combine des opérations IResource et java.io.File. Dans le cas de liaisons par exemple, le parent de IFile est différent de celui de java.io.File et le code les considérant identiques échouera.
Il était important que l'introduction de ressources liées ne rompe pas des fournisseurs par inadvertance. l'idée notamment portait sur les fournisseurs supposant que la structure du système de fichiers local est calquée sur celle du projet. De cette façon, les ressources liées ne peuvent par défaut pas être ajoutées à des projets mappés vers ce type de fournisseur. Par ailleurs, les projets contenant des ressources liées ne peuvent par défaut pas être partagés avec ce fournisseur.
Pour être "lié de manière conviviale", un fournisseur doit permettre le contrôle de la version des projets avec des ressources liées mais peut désactiver le contrôle de version des ressources liées proprement dites.
Une solution nettement plus complexe consisterait à autoriser le versionnage des ressources liées, sauf que cette option entraîne des scénarios fort alambiqués (par exemple, le fichier peut déjà être contrôlé par un autre fournisseur dans une autre arborescence de projet). Nous vous conseillons donc de prendre en charge les projets versionnés contenant des ressources liées non contrôlées en termes de version.
Les implémentations de fournisseurs de référentiels peuvent être mises à niveau afin de supporter des ressources liées. Pour ce faire, la méthode RepositoryProvider.canHandleLinkedResources() doit être remplacée afin de renvoyer la valeur true. Ainsi, les ressources liées peuvent exister dans des projets partagés avec ce fournisseur de référentiels. Toutefois, ce dernier doit prendre des mesures pour que les ressources liées soient correctement gérées. Comme expliqué auparavant, il est fort recommandé que les fournisseurs de référentiels ignorent toutes les ressources liées. Par conséquent, ces ressources (et leurs enfants) doivent être exclues des actions supportées par les fournisseurs. En outre, le fournisseur doit suivre le comportement de déplacement et de suppression par défaut si son implémentation remplace le IMoveDeleteHook par défaut.
Les fournisseurs d'équipe peuvent utiliser IResource.isLinked() pour savoir si une ressource est liée. Cependant, cette méthode renvoie uniquement la valeur true pour la racine d'une liaison. Le fragment de code peut servir à déterminer si une ressource est l'enfant d'une liaison.
String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();
les fournisseurs de référentiel doivent ignorer toute ressource pour laquelle le code ci-dessus parvient à true.
Les implémentations de référentiel utilisent souvent des fichiers et des dossiers supplémentaires pour stocker des informations spécifiques à leur principe. Même si ces fichiers sont requis dans l'espace de travail, ils ne présentent aucun intérêt pour les autres plug-in ou l'utilisateur final.
Les fournisseurs d'équipe peuvent utiliser IResource.setTeamPrivateMember(boolean) pour indiquer qu'une ressource est privée à l'implémentation d'un fournisseur d'équipe. Par défaut, les nouvelles ressources ne sont pas des membres privés ; cette méthode doit donc être utilisée pour marquer explicitement la ressource comme privée pour l'équipe. Il est fréquent de marquer le sous-dossier du projet comme privé lorsque ce dernier est configuré pour l'équipe et que le premier est créé.
Une autre API de ressources qui énumère les ressources (comme les arborescences de delta de ressources) excluent les membres privés d'équipe sauf s'il est expressément demandé de les inclure. Cela signifie que la plupart des clients ne "voient" pas les ressources privées d'équipe et que celles-ci ne peuvent pas être vues par l'utilisateur. Le navigateur de ressources n'affiche pas les membres privés d'équipe par défaut, mais les utilisateurs peuvent indiquer par le biais des Préférences qu'ils souhaitent afficher les ressources privées d'équipe.
Les tentatives pour marquer les projets ou la racine de l'espace de travail comme privés seront ignorées.
Sachant que les ressources d'un projet sous contrôle de version sont conservées dans le référentiel, des projets peuvent être partagés avec des membres de l'équipe grâce au partage d'une référence à des informations spécifiques au référentiel, nécessaires à la reconstruction d'un projet dans l'espace de travail. Pour ce faire, un type spécial d'exportation de fichier est requis pour les ensembles de projets d'équipe.
Dans la version 3.0, l'API a été ajoutée à ProjectSetCapability pour permettre aux fournisseurs de référentiel de déclarer une classe qui implémente l'enregistrement de projet pour les projets qu'ils contrôlent. Lorsque l'utilisateur choisit d'exporter des ensembles de projets, seuls les projets configurés avec des référentiels qui définissent des ensembles de projets sont affichés comme candidats à l'exportation. Cette API remplace l'ancienne API de sérialisation d'ensembles de projets (voir ci-dessous).
La classe de fonction d'ensemble de projets pour une fournisseur de référentiel est obtenue à partir de la classe RepositoryProviderType enregistrée dans la même extension que le fournisseur de référentiel. Par exemple :
<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>
Avant la version 3.0, le point d'extension org.eclipse.team.core.projectSets permettait aux fournisseurs de référentiel de déclarer une classe qui implémente l'enregistrement des projets qu'ils contrôlent. Lorsque l'utilisateur choisit d'exporter des ensembles de projets, seuls les projets configurés avec les référentiels qui définissent des ensembles de projets sont affichés comme candidats à l'exportation.
Par exemple, le client CVS déclare ce qui suit :
<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>
La classe spécifiée doit implémenter IProjectSetSerializer. L'utilisation de cette interface est toujours prise en charge dans la version 3.0, mais elle est déconseillée.