Per fornire un'assistenza completa per i modelli logici, un fornitore di repository può seguire le seguenti operazioni:
ResourceMapping
.ISynchronizationScope
e
supportando API.IMergeContext
e il supporto API.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.IFileHistoryProvider
APIProjectSetCapability
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.
L'associazione API di risorse utilizza le seguenti classi:
Oggetto getModelObject()
: L'oggetto di modello dal
quale deriva la mappatura (o adattata).ResourceTraversal[]
getTraversals(ResourceMappingContext, IProgressMonitor)
: Il passaggio
della risorsa che copre le risorse che costituiscono l'oggetto del modello.ResourceTraversal
contiene un gruppo di risorse e un
indicatore di profondità che indica la profondità alla quale le risorse nel
passaggio associate con l'oggetto di modello di origine. I passaggi
della risorsa sono forniti a un client da un'associazione di risorsa per
descrivere il contenuto di un modello in modo che il client (ad esempio un fornitore di repository) possa effettuare le operazioni in modo più efficiente possibile. I metodi di interesse sono:
getResources()
getDepth()
ResourceMappingContext
e RemoteResourceMappingContext
è un po' più complicato e viene descritto più avanti.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.
I plug-in che contribuiscono con estensioni ai punti di estensione adattabili
devono effettuare due modifiche per supportare il nuovo API ResourceMapping
:
ResourceMapping
invece di IResource
(per quelli per i quali è
appropriato).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
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:
ISynchronizationScope
:
interfaccia che definisce l'API per accedere all'ambito
dell'operazione. Fornisce accesso a tutte le mappature di risorsa
eseguite e i passaggi per quelle mappature come se fossero
calcolate durante il processo di creazione dell'ambito.ISynchronizationScopeManager
:
interfaccia che definisce l'API per la creazione e gestione di un ambito.SynchronizationScopeManager
:
classe estendibile che fornisce un'implementazione predefinita dell'APIISynchronizationScopeManager
.ModelOperation
:
classe di operazione estendibile che genera un ambito utilizzando un
gestore di ambiti e richiede se altre risorse o mappature aggiuntive sono state incluse
nell'operazione a causa delle relazioni tra i fornitori di modello.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:
RemoteResourceMappingContext
per l'uso
quando si ottengono passaggi di risorse dalle relative associazioni.SynchronizationScopeManager
per personalizzare
il processo di gestione dell'ambito quando richiesto.Le successive due sezioni descrivono questi punti più dettagliatamente.
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.
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:
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.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.
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.
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.
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:
ModelOperation
fornisce
una richiesta che utilizza i fornitori di contenuto team registrati per informare l'utente
di un'espansione di ambito.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:
ModelSynchronizeParticipant
ISynchronizePageConfiguration.P_VIEWER_ID
nell'id del visualizzatore specificato nella fase precedente.MergeActionGroup
per personalizzare
l'aspetto delle azioni relative all'unione.ModelParticipantMergeOperation
per la gestione della transizione da un'unione basata sul modello per un'anteprima in una
finestra di dialogo o vista di sincronizzazione.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>
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:
RepositoryProvider
associato con il progetto che
contiene la risorsa in un IHistoryPageSource.
IHistoryPageSource
.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.
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
.