Organigramme des référentiels pour l'intégration des modèles logiques

Pour fournir une prise en charge complète des modèles logiques, un fournisseur de référentiels peut réaliser les étapes suivantes :

  1. Ajouter les opérations de référentiel appropriées aux éléments qui s'adaptent à ResourceMapping.
  2. Vérifiez que les opérations effectuées sur les mappages de ressource incluent tous les éléments de modèle et les ressources appropriés à l'aide d'un élément ISynchronizationScope et d'une API de support.
  3. Permettre aux fournisseurs de modèle de participer à la fusion en arrière-plan par le biais de l'interface IMergeContext et de l'API de support.
  4. Permettre aux fournisseurs de modèle de participer aux aperçus de fusion à l'aide des modèles teamContentProviders pour les modèles impliqués dans la fusion. Une classe ModelSynchronizeParticipant est fournie pour faciliter la gestion de la relation entre le contenu du modèle, un contexte de fusion et l'infrastructure de comparaison.
  5. Fournir un accès à l'historique des fichiers de l'espace de travail via l'API IFileHistoryProvider
  6. Fournir un accès aux configurations distantes à l'aide de l'API de systèmes de fichiers Eclipse dans le plug-in org.eclipse.core.filesystem et le lier aux projets de l'espace de travail via ProjectSetCapability
  7. Prendre en charge la décoration d'élément de modèle logique en fournissant un espace de travail Subscriber à utiliser avec l'API SynchronizationStateTester.

Les sections suivantes décrivent plus en détail chacun de ces points. Le plug-in org.eclipse.team.examples.filesystem contient un exemple illustrant plusieurs de ces points. Vous pouvez réserver le projet du référentiel CVS et l'utiliser comme référence lorsque vous lisez ce didacticiel. Clause de protection : Le code source dans l'exemple de plug-in peut varier dans le temps. Pour obtenir une copie qui correspond à ce qui est utilisé dans cet exemple, vous pouvez réserver le projet à l'aide de la balise de version 3.2 (R3_2, le plus souvent) ou une balise de date du 28 juin 2006.

Ajout d'actions aux mappages de ressources

L'API de mappage des ressources de base

L'API de mappage des ressources comprend les classes suivantes :

Deux types de plug-ins devraient s'intéresser aux mappages des ressources. Ceux qui fournissent un modèle qui comprend des ressources, ou qui est conservé dans des ressources de l'espace de travail et ceux qui souhaitent effectuer des opérations sur les ressources. Le premier cas sera abordé dans la section relative à l'organigramme des modèles et le deuxième cas sera traité dans la section suivante.

Mappages de ressources et contributions d'objets

Les plug-ins qui ajoutent des extensions aux points d'extension adaptables devront apporter deux modifications pour prendre en charge les nouvelles API ResourceMapping :

  1. Mettre à jour les éléments objectContributions du point d'extension popupMenus dans leur fichier plugin.xml sur l'élément ResourceMapping cible au lieu de IResource (lorsque cela est approprié).
  2. Mettre à jour leurs actions pour fonctionner sur ResourceMapping au lieu de IResource et respecter les contraintes de profondeur fournies dans les balayages.

Les plug-ins qui ajoutent des contributions d'objets à IResource peuvent désormais les ajouter à ResourceMapping à la place, si l'action peut s'appliquer à plusieurs ressources. Dans l'exemple suivant, un fragment ajoute une action de menu aux objets qui s'adaptent aux mappages de ressources :

   <extension
       point="org.eclipse.ui.popupMenus">
      <objectContribution
            objectClass="org.eclipse.core.resources.mapping.ResourceMapping"
            adaptable="true"
            id="org.eclipse.team.ccvs.ui.ResourceMapperContributions">
         <enablement>
<adapt type="org.eclipse.core.resources.mapping.ResourceMapping">
<test
property="org.eclipse.core.resources.projectPersistentProperty"
args="org.eclipse.team.core.repository,org.eclipse.team.cvs.core.cvsnature" />
</adapt>
</enablement>
<action
label="%UpdateAction.label"
definitionId="org.eclipse.team.cvs.ui.update"
class="org.eclipse.team.internal.ccvs.ui.actions.UpdateAction"
tooltip="%UpdateAction.tooltip"
menubarPath="team.main/group2"
id="org.eclipse.team.cvs.ui.update">
</action>
...
</objectContribution>
</extension>

Les contributions à ResourceMapping s'appliqueront automatiquement aux objets qui s'adaptent à IResource. Cette association transitive est assurée par le plan de travail. Le filtrage des contributions aux mappages de ressources peut s'effectuer à l'aide d'expressions d'activation. Une expression permettant de filtrer par propriété permanente de projet a été ajoutée afin que les fournisseurs de référentiels puissent faire apparaître leurs menus dans les projets mappés sur leurs référentiels.

Les actions ayant été ajoutées à la classe ResourceMapping se verront attribuer une sélection contenant un ou plusieurs éléments ResourceMappings. Les actions ont pour rôle de convertir le mappage de ressources en un ensemble de ressources sur lesquelles effectuer des opérations. Cela peut s'effectuer en appelant getTraversals pour extraire les balayages du mappage. Les balayages permettent aux clients du balayage d'optimiser leurs opérations en fonction de la profondeur des ressources traversées. Un client peut accéder à la ressource manuellement ou utiliser la ressource et la profondeur comme entrée dans une opération dont l'action délègue l'exécution. A titre d'exemple, si l'utilisateur effectue une mise à jour CVS sur un package java et que le mappage de ressources du package java correspond à un dossier d'une profondeur de un, CVS lance alors une commande ("cvs update -l" pour ceux intéressés) destinée à effectuer une mise à jour superficielle sur le dossier représenté par le package.

Bien qu'il soit possible d'obtenir un ensemble de balayages directement à partir des mappages de ressources sélectionnés, des relations de modèles (ou des relations de référentiels) peuvent nécessiter l'inclusion de ressources ou d'éléments de modèles supplémentaires dans une opération. La section suivante explique comment vérifier que toutes les ressources requises sont incluses dans une opération

Portée d'opération

Pour les opérations d'équipe, les mappages sélectionnés doivent être convertis en ensemble de mappages sur lesquels effectuer des opérations. Ce processus implique de consulter tous les fournisseurs de modèle afin de s'assurer qu'ils sont inclus dans les opérations sur les ressources qui correspondent à leurs règles d'activation. Le terme que nous utilisons pour décrire le jeu complet de mappages de ressources sur lequel effectuer des opérations est la portée d'opération. L'API suivante a été fournie pour les éléments suivants :

La méthode initialize(IProgressMonitor) de la classe SynchronizationScopeManager assure le processus intégral de conversion d'un ensemble de mappages de ressources d'entrée en un ensemble complet de mappages sur lequel des opérations doivent être effectuées, ainsi que l'ensemble complet de balayages qui couvrent ces mappages. Un fournisseur de référentiels peut personnaliser le processus en :

  1. fournissant un élément RemoteResourceMappingContext à utiliser lors de l'extraction des balayages de ressource des mappages de ressources.
  2. Remplaçant SynchronizationScopeManager afin de personnaliser le processus de gestion de la portée, comme indiqué.

Les deux sections suivantes décrivent plus en détail chacun de ces points.

Contexte de mappage des ressources distantes

Pour s'assurer que toutes les ressources nécessaires sont incluses dans une opération d'équipe, le fournisseur de modèles peut avoir besoin de connaître l'état d'une ou de plusieurs ressources dans un référentiel. Pour certains modèles, cela peut ne pas être obligatoire. Par exemple, un package java est un conteneur visité à une profondeur de un, quel que soit l'état distant du modèle. En dépit de ceci, un fournisseur de référentiels peut aisément déterminer si des suppressions sortantes doivent être incluses lors de la validation ou si des ajouts entrants doivent être inclus lors de la mise à jour. Toutefois, les ressources qui constituent certains modèles logiques sont susceptibles de changer. Par exemple, les ressources qui constituent un élément de modèle peuvent dépendre du contenu d'un fichier manifeste (ou d'autres mécanismes similaires). Pour que le mappage des ressources renvoie le balayage correspond, il doit accéder au contenu distant du fichier manifeste (s'il diffère du contenu local) afin de voir si des ressources supplémentaires doivent être incluses. Ces ressources supplémentaires peuvent ne pas exister dans l'espace de travail mais le fournisseur de référentiels saurait le vérifier lors de l'exécution de l'action sélectionnée.

Pour prendre en charge ces modèles plus complexes, un élément RemoteResourceMappingContext peut être transmis à la méthode ResourceMapping#getTraversals. Lorsqu'un contexte est fourni, le mappage peut l'utiliser pour vérifier que toutes les ressources nécessaires sont incluses dans le balayage. Dans le cas contraire, le mappage peut présumer que seul l'état local est utile.

Le contexte de mappage de ressources distantes présente trois requêtes fondamentales :

La réponse à la première question posée précédemment dépend du type d'opération réalisée. En règle générale, les mises à jour et les fusions sont des comparaisons triples, tandis que les opérations de remplacement (du moins pour CVS) sont réciproques.

L'API Equipe Eclipse contient une classe Subscriber qui définit une API destinée à fournir l'état de synchronisation entre l'espace de travail local et un serveur distant. Une API SubscriberResourceMappingContext utilisant un élément Subscriber est fournie pour accéder à l'état distant requis. Les clients ayant un Subscriber n'ont pas besoin d'effectuer d'autres tâches pour obtenir un contexte de mappage de ressources.

Sous-classification de SynchronizationScopeManager

La classe SynchronizationScopeManager peut être sous-classée afin de personnaliser le processus de gestion et de génération de portée. Les deux raisons principales pour la sous-classification du gestionnaire de portée sont les suivantes :

  1. Le fournisseur de référentiels doit inclure des ressources supplémentaires en raison de relations au niveau du référentiel (exemple, ensemble de modifications). Cela peut s'effectuer en remplaçant la méthode adjustInputTraversals(ResourceTraversal[]).
  2. La synchronisation dispose d'une cycle de vie plus long (par exemple, vue Synchronisation contre boîte de dialogue) et doit avoir la possibilité de réagir aux changements de portée. L'interface ISynchronizationScopeParticipant définit l'API que les fournisseurs de modèle peuvent utiliser pour participer au processus de gestion de portée. La classe SubscriberScopeManager est une sous-classe de SynchronizationScopeManager basée sur un élément Subscriber qui implique les participants dans le processus de gestion de portée. La raison pour laquelle ce type de processus est nécessaire est illustrée par les jeux de documents. Si un jeu de documents est l'un des mappages de ressources dans une portée, l'ensemble des balayages couverts par la portée augmenterait si des ressources étaient ajoutées au jeu de documents.

Fusion basée sur un modèle

Le principal type d'opération de référentiel qui requiert la participation de modèle est la fusion. Dans de nombreux cas, les modèles n'ont besoin de participer qu'au niveau du fichier. Dans cette optique, l'API IStorageMerger a été introduite afin de permettre aux fournisseurs de modèle de contribuer aux dispositifs de fusion devant servir à fusionner les fichiers d'une extension ou d'un type de contenu. Toutefois, dans certains cas, les modèles peuvent nécessiter un contexte supplémentaire pour participer à une fusion de manière adéquate. A cet effet, nous avons introduit les API IResourceMappingMerger et IMergeContext.

Les opérations de fusion sont toujours déclenchées par des actions associées à un fournisseur de référentiels. Cependant, lorsqu'une opération de type fusion est demandée par l'utilisateur, le fournisseur de référentiels doit impliquer les fournisseurs de modèles dans le processus de fusion afin de s'assurer que l'opération n'altère pas le modèle.

Deux parties principales de l'API de fournisseur de référentiels sont associées au support de fusion basée sur les modèles.

  1. L'API permettant de décrire l'état de synchronisation des ressources impliquées dans la fusion.
  2. L'API permettant d'autoriser les fournisseurs de modèles à fusionner les éléments de modèle.
Les sections suivantes décrivent ces deux parties.

Description de l'API pour l'état de synchronisation

Un aspect important de la fusion basée sur un modèle est l'API servant à communiquer l'état de synchronisation des ressources impliquées pour le fournisseur de modèles. Les interfaces suivantes permettent de décrire l'état de synchronisation :

Les classes abstraites sont fournies pour toutes ces interfaces avec la convention selon laquelle les noms de classe correspondent aux noms d'interface dont le préfixe "I" est supprimé. La seule classe que les fournisseurs de référentiels doivent remplacer est la classe ResourceDiff, de sorte que les révisions de fichier antérieures et postérieures soient fournies.

API pour la fusion de modèle

L'interface IMergeContext étend le contexte de synchronisation avec des méthodes supplémentaires qui prennent en charge la fusion. Des méthodes de rappel existent pour :

Une classe abstraite MergeContext contenant des implémentations par défaut pour la plupart du comportement de fusion est fournie et utilise également l'API IStorageMerger pour effectuer des fusions tridirectionnelles. Une classe SubscriberMergeContext qui assure le remplissage et la gestion de l'état de synchronisation associé au contexte de fusion est également fournie.

Une classe d'opération, ModelMergeOperation qui utilise l'API IResourceMappingMerger pour effectuer une opération de fusion basée sur un modèle est fournie. Les sous-classes doivent remplacer la méthode initializeContext(IProgressMonitor) pour renvoyer un contexte de fusion. L'opération utilise ce contexte pour tenter une fusion basée sur un modèle en arrière-plan. En cas de conflits, l'aperçu de la fusion est laissé à la sous-classe. Chose que nous verrons dans la section suivante, une API ModelParticipantMergeOperation fournit des fonctions d'aperçu à l'aide de l'API ModelSynchronizeParticipant.

Contenu de modèle dans des afficheurs d'équipe

La prise en charge de l'affichage des modèles logiques dans une opération d'équipe est fournie à l'aide de l'infrastructure du navigateur commun qui a été introduite dans Eclipse 3.2. Les modèles logiques peuvent associer une extension de contenu à un fournisseur de modèles à l'aide du point d'extension org.eclipse.team.ui.teamContentProvider. Les fournisseurs d'équipe accèdent à ces fournisseurs de contenu via l'API ITeamContentProviderManager.

Un fournisseur d'équipe peut vouloir afficher des modèles logiques à de nombreux emplacements :

ModelSynchronizeParticipant fournit une intégration à la vue Synchronisation ou à tout conteneur capable d'afficher iSynchronizePages. Le participant utilise à la fois les fonctions de participation à la synchronisation pré-existantes et les fonctions du navigateur commun pour permettre aux fournisseurs d'équipe et aux modèles de personnaliser la barre d'outils, le menu contextuel et d'autres aspects de l'aperçu de fusion. ModelSynchronizeParticipant fournit les éléments suivants :

Voici une liste de contrôle des étapes à suivre pour personnaliser un participant de synchronisation de modèle pour un fournisseur d'équipe :

Les fragments suivants illustrent comment la classe du participant CVS est enregistrée et comment son afficheur est défini.

   <extension point="org.eclipse.team.ui.synchronizeParticipants">
      <participant
            name="CVS"
            icon="$nl$/icons/full/eview16/cvs_persp.gif"
            class="org.eclipse.team.internal.ccvs.ui.mappings.WorkspaceModelParticipant"
            id="org.eclipse.team.cvs.ui.workspace-participant">
      </participant>
   </extension>
   
   <extension point="org.eclipse.ui.navigator.viewer">
       <viewer viewerId="org.eclipse.team.cvs.ui.workspaceSynchronization">
           <popupMenu
                allowsPlatformContributions="false"
                id="org.eclipse.team.cvs.ui.workspaceSynchronizationMenu"> 
             <insertionPoint name="file"/>
             <insertionPoint name="edit" separator="true"/>       
             <insertionPoint name="synchronize"/>
             <insertionPoint name="navigate" separator="true"/>
             <insertionPoint name="update" separator="true"/>
             <insertionPoint name="commit" separator="false"/>
             <insertionPoint name="overrideActions" separator="true"/>
             <insertionPoint name="otherActions1" separator="true"/>
             <insertionPoint name="otherActions2" separator="true"/>
             <insertionPoint name="sort" separator="true"/>
             <insertionPoint name="additions" separator="true"/>             
             <insertionPoint name="properties" separator="true"/>
          </popupMenu>
       	</viewer>
   </extension>

Historique des fichiers

Une API d'historique des fichiers a été ajoutée pour permettre aux modèles d'accéder à l'historique des fichiers. L'API d'historique des fichiers comprend les interfaces suivantes :

En complément de cette API, une vue Historique de fichier générique a été ajoutée. Elle permet aux fournisseurs d'équipe d'afficher leur historique des ressources ou des fichiers dans une vue partagée, mais permet également aux modèles d'afficher l'historique des éléments de modèle pour les éléments qui ne mappent pas directement sur les fichiers. La vue Historique est une vue basée sur une page qui obtient une page pour l'élément sélectionné comme suit :

Fonction Jeu de projets

Des méthodes ont été ajoutées à ProjectSetCapability pour assurer la conversion entre une chaîne de référence permettant d'identifier un mappage entre un projet et un contenu distant et les URI qui identifient un schéma de système de fichiers enregistré avec le point d'extension org.eclipse.core.filesystem.filesystems. Les fournisseurs d'équipe peuvent de manière facultative fournir une prise en charge à cette fin pour permettre aux modèles logiques d'effectuer une navigation distante et un chargement des projets.

Décoration des éléments de modèle

Les fournisseurs d'équipe peuvent décorer les éléments de modèle en convertissant leurs décorateurs simples de façon à ce qu'ils fonctionnent pour les mappages de ressources exactement comme les contributions d'objets sont converties pour fonctionner pour les mappages de ressources. Toutefois, un aspect de la décoration d'éléments de modèle logique pose problème. Si un élément de modèle ne possède pas un mappage un à un sur une ressource, l'élément de modèle risque de ne pas recevoir de mise à jour de modèle lorsque les ressources sous-jacentes seront modifiées.

Pour résoudre cet incident, l'élément ITeamStateProvider a été introduit afin de permettre aux fournisseurs de modèle d'accéder aux modifications d'état susceptibles d'affecter les décorations d'équipe. Par ailleurs, les vues de modèle peuvent utiliser un élément SynchronizationStateTester pour déterminer lorsque les libellés des éléments de modèle logique doivent être mis à jour. Cette API recourt à l'interface ITeamStateProvider afin de déterminer lorsque l'état d'équipe de la ressource a changé et lorsqu'il peut être transmis à un décorateur d'équipe dans le cadre d'un IDecorationContext.