Descrizione del Repository per Logical Model Integration

Per fornire un'assistenza completa per i modelli logici, un fornitore di repository può seguire le seguenti operazioni:

  1. Contribuire alle operazioni di repository appropriate agli elementi che si adattano a ResourceMapping.
  2. Accertarsi che le operazioni effettuate sulle associazioni di risorsa includono tutti gli elementi e le risorse di modello appropriate utilizzando ISynchronizationScope e supportando API.
  3. Consentire ai fornitori di modello di partecipare all'unione headless mediante l'interfaccia IMergeContext e il supporto API.
  4. Consentire ai fornitori di modello di partecipare all'unione delle anteprime utilizzando teamContentProviders per i modelli inclusi nell'unione. Una classe ModelSynchronizeParticipant è fornita per consentire di gestire la relazione tra il contenuto del modello, un contesto di unione e il framework di confronto.
  5. Fornire accesso alla cronologia dei file dello spazio di lavoro mediante IFileHistoryProvider API
  6. Fornire accesso alle configurazioni remote utilizzando Eclipse File System API nel plug-in org.eclipse.core.filesystem e collegare questo ai progetti dello spazio di lavoro mediante ProjectSetCapability
  7. Supportare la decorazione di elemento di modello logico fornendo uno spazio di lavoro e Sottoscrittore per l'utilizzo con SynchronizationStateTester API.

Le seguenti sezioni descrivono ognuno di questi punti più dettagliatamente. Il plug-inorg.eclipse.team.examples.filesystem contiene un esempio che illustra diversi di questi punti. È possibile estrarre il progetto dal repository CVS e utilizzarlo come riferimento durante la lettura di questa esercitazione. Dichiarazione di responsabilità: il codice di origine nel plug-ins di esempio può cambiare con il tempo. Per avere una copia che corrisponde a quella utilizzata in questo esempio, è possibile estrarre il progetto utilizzando il tag della versione 3.2 (con maggiore probabilità R3_2) o un tag di data del 28 giugno 2006.

Azioni di contributo alle associazioni di risorse

L'Associazione API di risorse base

L'associazione API di risorse utilizza le seguenti classi:

Esistono due tipi di plugin che devono essere interessati nelle associazioni di risorsa. Quelli che forniscono un modello che è formato da o è archiviato in, risorse nello spazio di lavoro e quelli che vogliono effettuare operazioni sulle risorse. Il primo viene illustrato indescrizione modello e il secondo nella sezione successiva.

Associazioni di risorsa e contributi dell'oggetto

I plug-in che contribuiscono con estensioni ai punti di estensione adattabili devono effettuare due modifiche per supportare il nuovo API ResourceMapping:

  1. Aggiornare tutti i objectContributions del punto di estensione popupMenus nel file plugin.xml per indirizzarlo aResourceMapping invece di IResource (per quelli per i quali è appropriato).
  2. Aggiornare le azioni per farle funzionare su ResourceMapping invece di IResource e rispettare i vincoli di profondità forniti nei passaggi.

I plug-in che aggiungono contributi di oggetto a IResource adesso è possibile aggiungerli a ResourceMapping invece, se l'azione si può applicare alle risorse multiple. Ecco uno frammento XML che contribuisce a un'azione di menu agli oggetti che si adattano alle associazioni di risorsa:

   <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>

I contributi a ResourceMapping si applicano automaticamente agli oggetti che si adattano a IResource. Questa associazione transitiva è gestita dal Workbench. Il filtraggio dei contributi alle associazioni di risorsa può essere effettuato utilizzando le espressioni di abilitazione. Un'espressione per il filtraggio dalla proprietà persistente del progetto è stata aggiunta per consentire ai fornitori di repository di visualizzare i menu sui progetti che sono mappati nei repository.

Alle azioni che hanno contribuito alla classeResourceMapping viene fornita una selezione che contiene una o più ResourceMappings. Si tratta della responsabilità delle azioni per convertire l'associazione di risorsa in un gruppo di risorse sul quale operare. Questa operazione può essere effettuata utilizzando getTraversals per ottenere i passaggi dell'associazione. I passaggi sono utilizzati per consentire ai client del passaggio di ottimizzare le operazioni in base alla profondità delle risorse attraversate. Un client può attraversare la risorsa manualmente o utilizzare le risorsa e la profondità come inserimento in un'operazione che l'azione delega a eseguire questo lavoro. Ad esempio, se l'utente effettua un aggiornamento CVS su un pacchetto java e l'associazione di risorsa del pacchetto java si associa a una cartella di profondità uno, CVS emette un comando appropriato ("aggiornamento cvs -l" per quelli che sono curiosi) che esegue un aggiornamento superficiale sulla cartella che rappresenta il pacchetto.

Anche se è possibile ottenere un gruppo di passaggi direttamente dalle associazioni di risorse selezionate, ci sono relazioni di modello (o relazioni di repository) che possono richiedere l'inclusione di risorse aggiuntive o elementi di modelli in un'operazione. La sezione successiva descrive come garantire che tutte le risorse necessarie siano incluse in un'operazione

Ambito dell'operazione

Per le operazioni del team, le associazioni selezionate devono essere convertite nel gruppo di associazioni sul quale operare. Questo processo comporta la consultazione di tutti i fornitori di modello per garantire che siano inclusi nelle operazioni sulle risorse che corrispondono alle regole di abilitazione. Il termine utilizzato per descrivere il gruppo completo di associazioni di risorsa può essere messo in funzionamento scope. Il seguente API è stato fornito per questo:

Il metodo inizializzazione(IProgressMonitor) della classe SynchronizationScopeManager gestisce l'intero processo di conversione di un inserimento di un gruppo di associazioni di risorse nel gruppo completo di mappature che devono essere attivate, nonché il gruppo completo di passaggi che comprendono queste associazioni. Un fornitore di repository può personalizzare il processo:

  1. Fornendo un RemoteResourceMappingContext per l'uso quando si ottengono passaggi di risorse dalle relative associazioni.
  2. Ignorare SynchronizationScopeManager per personalizzare il processo di gestione dell'ambito quando richiesto.

Le successive due sezioni descrivono questi punti più dettagliatamente.

Contesto di mappatura di risorsa remota

Per garantire che tutte le risorse necessarie siano incluse in un'operazione di team, il fornitore di modelli potrebbe avere la possibilità di dare un'occhiata allo stato di una o più risorse nel repository. Per alcuni modelli, potrebbe non essere necessario. Ad esempio, un pacchetto java è un contenitore visitato in profondità uno, indipendentemente dallo stato remoto del modello. Dato questo, un provider di repository può facilmente stabilire che le eliminazioni in uscita devono essere incluse durante il commit o che le aggiunte in arrivo debbano essere incluse durante l'aggiornamento.Tuttavia, le risorse che costituiscono alcuni modelli logici possono cambiare nel tempo. Ad esempio, le risorse che costituiscono un elemento di modello dipendono dal contenuto di un file manifest (o qualche altro meccanismo simile). Affinché l'associazione di risorsa ritorni al passaggio corretto, deve accedere al contenuto remoto del file manifest (differisce dal contenuto locale) per vedere se ci sono risorse aggiuntive che devono essere incluse. Queste risorse aggiuntive possono non esistere nello spazio di lavoro, ma il fornitore di repository sa come accertarsi che erano presenti quando l'azione selezionata è stata eseguita.

Per supportare questi modelli più complessi, un RemoteResourceMappingContext può passare a un metodo ResourceMapping#getTraversals. Quando viene fornito un contesto, la mappatura può utililizzarlo per garantire che tutte le risorse necessarie siano incluse nel passaggio. Se un contesto non viene fornito, la mappatura può presumere che solo lo stato locale è di interesse.

Il contesto di mappatura di risorsa remota fornisce tre richieste di base:

La risposta alla prima domanda dipende dal tipo di operazione effettuata. In genere, gli aggiornamenti e le unioni sono a tre vie mentre le operazioni di confronto e sostituzione (almeno per CVS) sono a due vie.

L'Eclipse Team API include una classe Sottoscrittore che definisce un API per fornire lo stato di sincronizzazione tra lo spazio di lavoro locale e un server remoto. Viene fornito un SubscriberResourceMappingContext che utilizza un Subscriber per accedere allo stato remoto necessario. I client che hanno un Sottoscrittore non necessitano di ulteriore lavoro per accedere a un contesto di associazione di risorsa.

Creazione di sottoclassi per SynchronizationScopeManager

La classe SynchronizationScopeManager può essere sottoclassata per personalizzare la generazione dell'ambito e il processo di gestione. I due motivi principali per la creazione di sottoclassi del gestore ambiti sono:

  1. Il fornitore di repository deve includere risorse aggiuntive a causa di qualche relazione a livello del repository (ad esempio gruppo di modifica). Quest'operazione può essere effettuata ignorando il metodo adjustInputTraversals(ResourceTraversal[]).
  2. La sincronizzazione ha un ciclo di vita più lungo (ad esempio Sincronizza vista rispetto a finestra di dialogo) e ha bisogno di potenziale per reagire alle modifiche di ambito. L'interfaccia ISynchronizationScopeParticipant definisce l'API che i fornitori di modelli possono utilizzare per partecipare al processo di gestione dell'ambito. La classe SubscriberScopeManager è un Sottoscrittore basato sulla sottoclasse di SynchronizationScopeManager che coinvolge i partecipanti nel processo di gestione dell'ambito. Un esempio di perché questo tipo di processo è necessario è nei gruppi di lavoro Se un gruppo di lavoro è una delle associazioni di risorsa in un ambito, il gruppo di passaggi coperti dall'ambito aumenta se le risorse sono state aggiunte al gruppo di lavoro.

Unione basata sul modello

Il tipo di operazione del repository principale che richiede la partecipazione del modello è l'unione. In molti casi, i modelli devono solo partecipare a livello del file. Per questo, l'API IStorageMerger è stato introdotto per consentire ai fornitori di modello di contribuire con le unità di unione della che devono essere utilizzati ad unire i file di un'estensione particolare o tipo di contenuto. Tuttavia, in alcuni casi, i modelli possono richiedere ulteriore contesto per partecipare correttamente a un'unione. A questo obiettivo, abbiamo introdotto gli API IResourceMappingMerger e IMergeContext.

Le operazioni di unione sono ancora azionate dalle azioni associate con un fornitore di repository. Tuttavia, una volta che un'operazione del tipo di unione è richiesta dall'utente, il fornitore di repository deve includere i fornitori di modello nel processo di unione per garantire che l'unione non corrompe il modello in qualche modo.

Ci sono due pezzi principali nell'API del fornitore di repository associato al supporto di unione basato sul modello.

  1. L'API per descrivere lo stato di sincronizzazione delle risorse coinvolte nell'unione.
  2. L'API per consentire ai fornitori di modello di unire gli elementi di modello.
Le seguenti sezioni descrivono questi due pezzi.

API per descrizione dello stato di sincronizzazione

Un aspetto importante dell'unione basata sul modello è l'API utilizzato per comunicare lo stato di sincronizzazione delle risorse coninvolte nel fornitore di modello. Le seguenti interfacce sono utilizzate per descrivere lo stato di sincronizzazione:

Le classi astratte sono fornite per tutte queste interfacce con la convenzione che i nomi di classe corrispondono ai nomi di interfaccia con il prefisso"I" rimosso. La sola classe che i fornitori di repository devono ignorare è la classe ResourceDiff in modo da poter fornire le revisioni appropriate ai file precedenti e successivi.

API per l'unione di modelli

L'interfaccia IMergeContext estende il contesto di sincronizzazione con metodi aggiuntivi che supportano l'unione. I metodi di richiamata esistono per:

Viene fornito un astratto della classeMergeContext che contiene implementazioni predefinite per la maggior parte del comportamento di unione e utilizza anche IStorageMerger per effettuare le unioni a tre vie. Viene anche fornita una classe SubscriberMergeContext che gestisce l'inserimento e la manutenzione della descrizione dello stato di sincronizzazione associato con il contesto di unione.

Una classe di operazioni, ModelMergeOperation viene fornita che utilizza l'API IResourceMappingMerger per eseguire l'operazione di unione basata sul modello. Le sottoclassi devono ignorare il metodo initializeContext(IProgressMonitor) per ritornare al contesto di unione. L'operazione utilizza questo contesto per provare un'unione basta sul modello headless. Se esiste il conflitto, l'anteprima dell'unione viene lasciata nella sottoclasse. Come vedremo nella sezione successiva, c'è un ModelParticipantMergeOperation che fornisce le capacità di anteprima utilizzando un ModelSynchronizeParticipant.

Contenuto del modello in visualizzatori di team

Il supporto per la visualizzazione di modelli logici in un'operazione di team viene fornito utilizzando il framework Common Navigator che è stato introdotto in Eclipse 3.2. I modelli logici possono associare un'estensione del contento con un fornitore di modelli utilizzando il punto di estensioneorg.eclipse.team.ui.teamContentProvider. I fornitori di team accedono a questi fornitori di contenuto mediante ITeamContentProviderManager.

Ci sono diverse posizioni in cui un fornitore di team può decidere di visualizzare i modelli logici:

Il ModelSynchronizeParticipant fornisce integrazione nella vista Sincronizza o qualsiasi contenitore che può visualizzare iSynchronizePages. Il partecipante utilizza entrambe le capacità del partecipante di sincronizzazione esistenti e le funzioni di Common Navigator per consentire ai fornitori di team e modelli di personalizzare la barra degli strumenti, il menu di contesto e gli altri aspetti dell'anteprima di unione. Il ModelSynchronizeParticipant fornisce i seguenti:

Ecco un elenco di fasi di personalizzazione di un partecipante alla sincronizzazione del modello per un particolare fornitore di Team:

I seguenti frammenti XML illustrano come la classe di partecipanti CVS viene registrata e come il visualizzatore è definito.

   <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>

Cronologia file

Una cronologia di file API è stata aggiunta per consentire ai modelli di accedere alla cronologia dei file. L'API della cronologia dei file è composta dalle seguenti interfacce:

Insieme a questo API, una vista di cronologia di file generica è stata aggiunta. Questa consente ai fornitori di team di visualizzare la cronologia di file/risorse 8960387 in una vista condivisa e consente anche ai modelli di visualizzare la cronologia di elemento di modello per gli elementi che non si associano direttamente ai file. La vista Cronologia è una vista basata sulla pagina che ottiene una pagina per l'elemento selezionato nel seguente modo:

Funzionalità dell'insieme progetti

I metodi che sono stati aggiunti a ProjectSetCapability per supportare la conversione tra la stringa di riferimento utilizzata per identificare un'associazione tra un progetto e il contenuto remoto e gli URI che identificano uno schema di file-system registrato con il punto di estensione org.eclipse.core.filesystem.filesystems. I fornitori di team possono opzionalmente fornire supporto per questo per consentire ai modelli logici di effettuare un'esplorazione remota e il caricamento del progetto.

Decorazione di elementi di modello

I fornitori di team possono decorare elementi di modello convertendo i decoratori semplificativi per lavorare con le associazioni di risorsa allo stesso modo in cui i contributi di oggetti sono convertiti per lavorare con le associazioni di risorsa. Tuttavia, c'è solo un aspetto di decorazione di elemento di modello logico che è problematico. Se un elemento di modello non ha un'associazione uno a uno in una risorsa, l'elemento di modello potrebbe non ricevere un aggiornamento di etichetta quando le risorse sottostanti cambiano.

Per risolvere questo problema, il ITeamStateProvider è stato introdotto per dare ai fornitori di modello l'accesso alle modifiche di stato che possono influenzare le decorazioni di team. Inoltre, le viste di modello possono utilizzare un SynchronizationStateTester per determinare quando le etichette degli elementi di modello logico devono essere aggiornate. Questo API conta sull'interfaccia ITeamStateProvider per determinare quando lo stato di team della risorsa è cambiato e può essere passato a un decoratore di team come parte di un IDecorationContext.