Mit den folgenden Schritten kann ein Repository-Provider eine vollständige Unterstützung für logische Modelle bereitstellen:
ResourceMapping
übernehmen.ISynchronizationScope
und eine unterstützende API verwendet.IMergeContext
und die unterstützende API wird es Modellprovidern ermöglicht, an automatischen Mischvorgängen teilzunehmen.teamContentProvider
für die am Mischvorgang beteiligten Modelle wird es Modellprovidern ermöglicht, an Vorschauen für Mischvorgänge teilzunehmen. Um die Beziehung zwischen dem Modellinhalt, einem Mischkontext und einem Vergleichsgerüst zu verwalten, wird eine Klasse ModelSynchronizeParticipant
bereitgestellt.IFileHistoryProvider
ermöglicht.ProjectSetCapability
hergestellt.
Subscriber
für den Arbeitsbereich unterstützt, die mit der API SynchronizationStateTester
verwendet wird.Die folgenden Abschnitte beschreiben die obigen Aspekte ausführlicher. Das Plug-in org.eclipse.team.examples.filesystem enthält ein Beispiel, das einige dieser Punkte veranschaulicht. Sie können das Projekt aus dem CVS-Repository auschecken und während dieses Lernprogramms als Referenz verwenden. Hinweis: Der Quellcode der Beispiel-Plug-ins kann sich im Laufe der Zeit ändern. Um eine Kopie zu erhalten, die diesem Beispiel entspricht, können Sie das Projekt mit der Kennung der Version 3.2 (wahrscheinlich R3_2) oder einer Datumskennung vom 28. Juni 2006 auschecken.
Die API für die Ressourcenzuordnung besteht aus den folgenden Klassen:
Object getModelObject()
: Das Modellobjekt, aus dem die Zuordnung abgeleitet (also übernommen) wurde.ResourceTraversal[]
getTraversals(ResourceMappingContext, IProgressMonitor)
: Die Ressourcentraversierung, die die Ressourcen abdeckt, aus denen das Modellobjekt besteht.ResourceTraversal
enthält eine Reihe von Ressourcen sowie ein Attribut für die Verschachtelungstiefe, das die Tiefe angibt, in der die Ressourcen in der Traversierung dem entsprechenden Modellobjekt zugeordnet sind. Ressourcentraversierungen werden für einen Client durch eine Ressourcenzuordnung bereitgestellt, um den Inhalt eines Modells so zu beschreiben, dass der Client (z. B. ein Repository-Provider) seine Operationen so effizient wie möglich ausführen kann. Wichtige Methoden:getResources()
getDepth()
ResourceMappingContext
und RemoteResourceMappingContext
ist etwas komplexer und wird an einer anderen Stelle erläutert.Es gibt zwei Typen von Plug-ins, die für Ressourcenzuordnungen wichtig sind. Zum einen handelt es sich hierbei um Plug-ins, von denen ein Modell bereitgestellt wird, das aus Ressourcen im Arbeitsbereich besteht bzw. in diesen permanent enthalten ist, sowie um Plug-ins, die Operationen für Ressourcen ausführen sollen. Der erste Plug-in-Typ wird in der Modellübersicht erläutert. Der zweite Typ wird im nächsten Abschnitt behandelt.
Plug-ins, die übernahmefähige Erweiterungspunkte durch Erweiterungen ergänzen, müssen zwei Änderungen vornehmen, um
die neuen APIs der Klasse ResourceMapping
zu unterstützen:
ResourceMapping
anstelle von IResource
als Ziel angeben (wo dies geeignet ist).ResourceMapping
anstelle von IResource
verwenden und die Integritätsbedingungen für die Verschachtelungstiefe beachten, die in den Traversierungen angegeben sind.Plug-ins, die IResource
durch Objektergänzungen erweitern, können diese nun
stattdessen zu ResourceMapping
hinzufügen, falls die Aktion auf mehrere Ressourcen angewendet werden kann. Der folgende XML-Ausschnitt ergänzt Objekte, die Ressourcenzuordnungen übernehmen, durch eine Menüaktion:
<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>
Ergänzungen für ResourceMapping
werden automatisch auf alle Objekte angewendet,
die IResource
übernehmen. Diese transitive Zuordnung wird durch die Workbench verarbeitet. Das Filtern der Ergänzungen für Ressourcenzuordnungen kann unter Verwendung von Aktivierungsausdrücken erfolgen. Es wurde ein Ausdruck für die Filterung nach der Projekteigenschaft für die Permanenz hinzugefügt. Er versetzt Repository-Provider in die Lage, ihre Menüs für Projekte anzuzeigen, die ihren Repositorys zugeordnet sind.
Aktionen, mit denen die Klasse ResourceMapping
ergänzt wurde, erhalten eine
Auswahl, die eines oder mehrere Elemente ResourceMapping
enthält.
Die Aktionen müssen die Ressourcenzuordnung in eine Gruppe von Ressourcen umsetzen, für die Operationen ausgeführt werden können. Dies kann durch den Aufruf von getTraversals
erfolgen, mit dem die Traversierungen der Zuordnung abgerufen werden. Mithilfe von Traversierungen können die Clients der Traversierung ihre Operationen basierend auf der Verschachtelungstiefe der traversierten Ressourcen optimieren. Ein Client kann die Ressource manuell traversieren oder auch die Ressource und die Verschachtelungstiefe als Eingabe für eine Operation verwenden, an die die Durchführung von der Aktion delegiert wurde. Falls der Benutzer beispielsweise eine CVS-Aktualisierung für ein Java-Paket ausführt und die Ressourcenzuordnung des Java-Pakets für die Zuordnung einen Ordner mit einer Verschachtelungstiefe von einer Ebene angibt, setzt CVS einen entsprechenden Befehl ab (nämlich "cvs update -l"), der eine flache Aktualisierung für den durch das Paket dargestellten Ordner durchführt.
Es ist zwar möglich, die Gruppe der Traversierungen direkt aus den ausgewählten Ressourcenzuordnungen abzurufen, aber es gibt Modellbeziehungen (oder Repositorybeziehungen), bei denen möglicherweise zusätzliche Ressourcen oder Modellelemente in eine Operation einbezogen werden müssen. Im nächsten Abschnitt wird erläutert, wie Sie sicherstellen können, dass alle erforderlichen Ressourcen in einer Operation enthalten sind.
Bei Teamoperationen müssen die ausgewählten Zuordnungen in die Gruppe der Zuordnungen umgesetzt werden, für die Operationen ausgeführt werden. Im Rahmen dieses Prozesses werden alle Modellprovider angesprochen, um sicherzustellen, dass sie in Operationen für Ressourcen einbezogen werden, die mit ihren Aktivierungsregeln übereinstimmen. Die vollständige Gruppe der Ressourcenzuordnungen, für die Operationen ausgeführt werden, wird als Operationsbereich bezeichnet. Zu diesem Zweck wurde die folgende API bereitgestellt:
ISynchronizationScope
:
Diese Schnittstelle definiert die API für den Zugriff auf den Operationsbereich. Sie ermöglicht den Zugriff auf alle Ressourcenzuordnungen, für die Operationen ausgeführt werden, sowie auf die Traversierungen für diese Zuordnungen, die während des Erstellungsprozesses für den Bereich berechnet wurden.ISynchronizationScopeManager
:
Diese Schnittstelle definiert die API für die Erstellung und Verwaltung eines Bereichs.SynchronizationScopeManager
:
Diese erweiterbare Klasse bietet eine Standardimplementierung der API ISynchronizationScopeManager
.ModelOperation
:
Diese erweiterbare Operationsklasse generiert unter Verwendung eines bereitgestellten Bereichsmanagers einen Bereich und gibt eine Anforderung aus, falls zusätzliche Ressourcen oder Zuordnungen aufgrund der Modellproviderbeziehungen in die Operation einbezogen sind.Die Methode initialize(IProgressMonitor) der Klasse SynchronizationScopeManager
verarbeitet den gesamten Prozess der Konvertierung einer Eingabegruppe von Ressourcenzuordnungen in die vollständige Gruppe der Zuordnungen, für die Operationen ausgeführt werden müssen, sowie die vollständige Gruppe der Traversierungen, die diese Zuordnungen abdecken. Ein Repository-Provider kann den Prozess folgendermaßen anpassen:
RemoteResourceMappingContext
für den Abruf der Ressourcentraversierungen aus den Ressourcenzuordnungen.SynchronizationScopeManager
, um den Prozess der Bereichsverwaltung wie erforderlich anzupassen.Diese beiden Aspekte werden in den folgenden Abschnitten ausführlicher erläutert.
Um garantieren zu können, dass alle erforderlichen Ressourcen in eine Teamoperation einbezogen werden, muss der Modellprovider möglicherweise in der Lage sein, den Status von einer oder mehreren Ressourcen im Repository zu ermitteln. Bei manchen Modellen ist dies möglicherweise nicht erforderlich. Ein Java-Paket ist beispielsweise ein Container, der - unabhängig vom fernen Status des Modells - nur eine Tiefenebene aufweist, die verwendet werden kann. Infolgedessen kann ein Repositoryprovider ohne großen Aufwand feststellen, dass beim Festschreiben abgehende Löschvorgänge oder bei der Aktualisierung eingehende Ergänzungen aufgenommen werden sollten. Es kann jedoch sein, dass sich die Ressourcen, aus denen sich einige logische Modelle zusammensetzen, mit der Zeit ändern. So sind die Ressourcen, die ein Modellelement bilden, möglicherweise vom Inhalt einer Manifestdatei (oder einem anderen ähnlichen Mechanismus) abhängig. Damit die Ressourcenzuordnung die richtige Traversierung zurückgibt, muss sie auf den fernen Inhalt der Manifestdatei zugreifen (falls dieser sich vom lokalen Inhalt unterscheidet), um feststellen zu können, ob zusätzliche Ressourcen aufgenommen werden müssen. Diese zusätzlichen Ressourcen sind zwar unter Umständen nicht im Arbeitsbereich vorhanden, aber der Repository-Provider ist in diesem Fall in der Lage sicherzustellen, dass sie bei einer Ausführung der ausgewählten Aktion zur Verfügung stehen.
Um diese komplexeren Modelle zu unterstützen, kann ein Objekt RemoteResourceMappingContext
an die Methode ResourceMapping#getTraversals
übergeben werden.
Wenn ein Kontext zur Verfügung steht, kann die Zuordnung mithilfe dieses Objekts sicherstellen, dass alle erforderlichen Ressourcen in der Traversierung enthalten sind. Wird kein Kontext bereitgestellt, kann die Zuordnung davon ausgehen, dass nur der lokale Status von Bedeutung ist.
Der ferne Ressourcenzuordnungskontext bietet drei Standardabfragen:
Die Antwort auf die erste der obigen Fragen ist vom Typ der ausgeführten Operation abhängig. Normalerweise handelt es sich bei Aktualisierungen und Mischvorgängen um Dreifachoperationen, während Vergleiche und Ersetzungen (zumindest bei CVS) Zweifachoperationen sind.
Die Team-API von Eclipse enthält eine Klasse Subscriber
, die eine API für die Bereitstellung des Synchronisationsstatus' zwischen einem lokalen Arbeitsbereich und einem fernen Server definiert. Es wird ein Element SubscriberResourceMappingContext
bereitgestellt, das die Klasse Subscriber
verwendet, um auf den benötigten fernen Status zuzugreifen. Clients, die über eine Klasse Subscriber
verfügen, müssen keine weiteren Aktionen ausführen, um einen Ressourcenzuordnungskontext abzurufen.
Aus der Klasse SynchronizationScopeManager
können Unterklassen gebildet werden, um den Prozess der Bereichsgenerierung und -verwaltung anzupassen. Für die Unterklassenbildung aus dem Bereichsmanager sprechen hauptsächlich die beiden folgenden Gründe:
ISynchronizationScopeParticipant
definiert die API, mit denen Modellprovider am Bereichsverwaltungsprozess teilnehmen können. Die Klasse SubscriberScopeManager
ist eine auf Subscriber
basierende Unterklasse von SynchronizationScopeManager
, die Teilnehmer in den Bereichsverwaltungsprozess einbindet. Dieser Prozesstyp wird beispielsweise bei Arbeitssets benötigt. Falls es sich bei einer der Ressourcenzuordnungen in einem Bereich um ein Arbeitsset handelt, würde sich die Gruppe der Traversierungen, die durch den Bereich abgedeckt werden, vergrößern, falls Ressourcen zum Arbeitsset hinzugefügt werden.Der wichtigste Operationstyp für Repositorys, der eine Modellteilnahme erfordert, ist der Mischvorgang. In vielen Fällen müssen Modelle nur auf Dateiebene teilnehmen. Hierzu wurde die API IStorageMerger
eingeführt, damit Modellprovider Mischfunktionen bereitstellen können, die zum Mischen von Dateien eines bestimmten Erweiterungs- oder Inhaltstyps verwenden werden müssen. In manchen Fällen benötigen Modelle jedoch möglicherweise zusätzlichen Kontext, um korrekt an einem Mischvorgang mitwirken zu können. Zu diesem Zweck wurden die APIs IResourceMappingMerger
und IMergeContext
eingeführt.
Mischoperationen werden weiterhin durch Aktionen ausgelöst, die einem Repository-Provider zugeordnet sind. Sobald eine Mischoperation durch den Benutzer angefordert wird, muss der Repository-Provider jedoch die Modellprovider in den Mischvorgang einbeziehen, um sicherzustellen, dass der Mischvorgang das Modell nicht auf irgendeine Weise beschädigt.
Im Zusammenhang mit der modellbasierten Unterstützung für Mischvorgänge gibt es zwei Haupt-APIs für den Repository-Provider.
Ein wichtiger Aspekt des modellbasierten Mischvorgangs ist die API, mit deren Hilfe dem Modellprovider der Synchronisationsstatus der beteiligten Ressourcen mitgeteilt wird. Der Synchronisationsstatus wird mit den folgenden Schnittstellen beschrieben:
Für alle diese Schnittstellen werden abstrakte Klassen bereitgestellt. Hierbei gilt die Konvention, dass die Klassennamen den Schnittstellennamen entsprechen, das vorangestellte "I" jedoch entfernt wird. Die einzige Klasse, die von Repository-Providern überschrieben werden muss, ist die Klasse ResourceDiff
. Dies ist erforderlich, damit der Status der Datei vor und nach Überarbeitungen bereitgestellt werden kann.
Die Schnittstelle IMergeContext erweitert den Synchronisationskontext durch zusätzliche Methoden, die Mischvorgänge unterstützen. Callbackmethoden gibt es für:
Es wird die abstrakte Klasse MergeContext bereitgestellt, die Standardimplementierungen für einen Großteil des Mischverhaltens enthält und außerdem die Schnittstelle IStorageMerger verwendet, um Dreifachmischvorgänge auszuführen. Des Weiteren wird die Klasse SubscriberMergeContext bereitgestellt, von der die Füllung und Verwaltung der Beschreibung für den Synchronisationsstatus verarbeitet wird, der dem Mischkontext zugeordnet ist.
Es wird die Operationsklasse ModelMergeOperation
bereitgestellt, die unter Verwendung der API IResourceMappingMerger
einen modellbasierten Mischvorgang ausführt. Unterklassen müssen die Methode initializeContext(IProgressMonitor)
überschreiben, um einen Kontext für den Mischvorgang zurückzugeben. Die Operation verwendet diesen Kontext für den Versuch eines automatischen modellbasierten Mischvorgangs. Falls Konflikte vorhanden sind, wird die Vorschau für den Mischvorgang an die Unterklasse übergeben. Im nächsten Abschnitt wird das Element
ModelParticipantMergeOperation
vorgestellt, das unter Verwendung von der Klasse ModelSynchronizeParticipant Vorschaufunktionen bereitstellt.
Die Unterstützung für das Anzeigen logischer Modelle in einer Teamoperation wird unter Verwendung des allgemeinen Navigatorgerüsts bereitgestellt, das in Eclipse 3.2 eingeführt wurde. Logische Modelle können einem Modellprovider
unter Verwendung des Erweiterungspunkts org.eclipse.team.ui.teamContentProvider
eine Inhaltserweiterung zuordnen. Team-Provider greifen über die Schnittstelle ITeamContentProviderManager
auf diese Inhaltsprovider zu.
Das Anzeigen logischer Modelle ist für einen Team-Provider in verschiedenen Situationen wünschenswert:
ModelOperation
stellt eine Bedienerführung bereit, die unter Verwendung der registrierten Teaminhaltsprovider den Benutzer vor einer Erweiterung des Bereichs unterrichtet.Die Klasse ModelSynchronizeParticipant
stellt die Integration in die Sicht "Synchronisieren" oder einen anderen Container bereit, der Elemente iSynchronizePages
anzeigen kann.
Der Teilnehmer verwendet sowohl die bereits vorhandenen Synchronisationsteilnehmerfunktionen als auch die allgemeinen Navigatorfunktionen, damit Team-Provider und Modelle die Symbolleiste, das Kontextmenü und andere Aspekte der Vorschau für den Mischvorgang anpassen können. Die Klasse ModelSynchronizeParticipant
stellt Folgendes zur Verfügung:
Die folgende Checkliste enthält die Schritte, mit denen ein Teilnehmer an einer Modellsynchronisierung für einen bestimmten Team-Provider angepasst werden kann:
ModelSynchronizeParticipant
durch die Team-Provider erforderlich.ISynchronizePageConfiguration.P_VIEWER_ID
auf die ID der Anzeigefunktion zu setzen, die Sie im vorherigen Schritt angegeben haben.MergeActionGroup
bereitzustellen, mit der Sie die Darstellung der Aktionen für den Mischvorgang anpassen können.ModelParticipantMergeOperation
, um den Übergang von einem modellbasierten Mischvorgang zu einer Vorschau in einem Dialog oder einer Sicht "Synchronisieren" zu verarbeiten.Die folgenden XML-Ausschnitte veranschaulichen, wie die Klasse des CVS-Teilnehmers registriert und seine Anzeigefunktion definiert wird:
<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>
Es wurde eine Dateiprotokoll-API hinzugefügt, mit deren Hilfe Modelle auf das Protokoll von Dateien zugreifen können. Die Dateiprotokoll-API besteht aus den folgenden Schnittstellen:
Zusammen mit dieser API wurde eine Sicht für das generische Dateiprotokoll hinzugefügt. Hierdurch können Team-Provider ihr Datei-/Ressourcenprotokoll in einer gemeinsamen Sicht anzeigen. Außerdem erhalten Modelle die Möglichkeit, ein Modellelementprotokoll für Elemente anzuzeigen, die keinen Dateien direkt zugeordnet sind. Die Sicht "Protokoll" ist eine seitenbasierte Sicht, die für das ausgewählte Element folgendermaßen eine Seite abruft:
RepositoryProvider
, das dem Projekt mit der Ressource zugeordnet ist, in einer Schnittstelle IHistoryPageSource übernommen wird.
IHistoryPageSource
übernommen wird.In die Klasse ProjectSetCapability
wurden Methoden aufgenommen, um die Umsetzung zwischen einer Verweiszeichenfolge, mit der eine Zuordnung zwischen einem Projekt und fernem Inhalt angegeben wird, und URIs vorzunehmen, die ein am Erweiterungspunkt
org.eclipse.core.filesystem.filesystems registriertes Dateisystemschema angeben. Team-Provider können diese Unterstützung optional bereitstellen, damit logische Modelle Projekte über Remotezugriff anzeigen und laden können.
Team-Provider können Modellelemente mit Dekoratoren versehen, indem sie ihre einfachen Dekoratoren so konvertieren, dass sie zusammen mit Ressourcenzuordnungen verwendet werden können. Die Konvertierung erfolgt genauso wie bei Objektergänzungen, die für die Zusammenarbeit mit Ressourcenzuordnungen konvertiert werden. Es gibt jedoch einen problematischen Aspekt bei der Dekoration von logischen Modellelementen. Falls ein Modellelement keine Eins-zu-eins-Zuordnung zu einer Ressource aufweist, empfängt das Modellelement möglicherweise keine Bezeichnungsaktualisierung, wenn sich die zu Grunde liegende Ressource ändert.
Um dieses Problemstellung zu lösen, wurde ITeamStateProvider
eingeführt, damit Modellprovider auf Statusänderungen zugreifen können, die sich möglicherweise auf Teamdekorationen auswirken. Außerdem können Modellsichten mit der Testfunktion
SynchronizationStateTester
ermitteln, ob die Bezeichnungen von logischen Modellelementen aktualisiert werden müssen. Diese API nutzt die Schnittstelle ITeamStateProvider
, um zu ermitteln, ob sich der Teamstatus einer Ressource geändert hat und als Teil von IDecorationContext
an einen Teamdekorator übergeben werden kann.