Pour fournir une prise en charge complète des modèles logiques, un fournisseur de référentiels peut réaliser les étapes suivantes :
ResourceMapping
.ISynchronizationScope
et d'une API de support.IMergeContext
et de l'API de support.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.IFileHistoryProvider
ProjectSetCapability
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.
L'API de mappage des ressources comprend les classes suivantes :
Object getModelObject()
: L'objet de modèle dont découle le mappage (ou adapté).ResourceTraversal[]
getTraversals(ResourceMappingContext, IProgressMonitor)
: Le balayage de ressource qui couvre les ressources qui forment l'objet de modèle.ResourceTraversal
contient un ensemble de ressources ainsi qu'un indicateur de profondeur qui signale à quelle profondeur les ressources situées dans le balayage sont associées à l'objet de modèle d'origine. Des balayages de ressource sont fournis à un client par un mappage de ressource afin de décrire le contenu d'un modèle de sorte que le client (un fournisseur de référentiel) puisse effectuer ses opérations aussi efficacement que possible. Les méthodes conseillées sont les suivantes :
getResources()
getDepth()
ResourceMappingContext
et de RemoteResourceMappingContext
est plus compliquée et fait l'objet d'une description ultérieure.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.
Les plug-ins qui ajoutent des extensions aux points d'extension adaptables devront apporter deux modifications pour prendre en charge les nouvelles API ResourceMapping
:
ResourceMapping
cible au lieu de IResource
(lorsque cela est approprié).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
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 :
ISynchronizationScope
:
Interface définissant l'API permettant d'accéder à la portée de l'opération. Elle fournit un accès à tous les mappages de ressource sur lesquels sont effectuées des opérations et les balayages de ces mappages tels qu'ils ont été calculés au cours du processus de génération de la portée.ISynchronizationScopeManager
:
Interface définissant l'API qui permet de créer et de gérer une portée.SynchronizationScopeManager
: Classe extensible qui fournit une implémentation par défaut de l'API ISynchronizationScopeManager
.ModelOperation
:
Classe d'opération extensible qui génère une portée à l'aide d'un gestionnaire de portée fourni et demande si des ressources ou des mappages supplémentaires ont été inclus dans l'opération en raison de relations de fournisseurs de modèles.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 :
RemoteResourceMappingContext
à utiliser lors de l'extraction des balayages de ressource des mappages de ressources.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.
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.
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 :
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.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.
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.
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.
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 :
ModelOperation
fournit une invite qui utilise les fournisseurs de contenu d'équipe enregistrés pour informer l'utilisateur d'une extension de portée.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 :
ModelSynchronizeParticipant
ISynchronizePageConfiguration.P_VIEWER_ID
l'ID de l'afficheur indiqué à l'étape précédente.MergeActionGroup
pour personnaliser l'aspect des actions liées à la fusion.ModelParticipantMergeOperation
pour assurer la transition d'une fusion basée sur un modèle vers un aperçu dans une boîte de dialogue ou une vue Synchronisation.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>
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 :
RepositoryProvider
associé au projet et qui contient la ressource à un IHistoryPageSource.
IHistoryPageSource
.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.
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
.