Repository-Übersicht für die Integration logischer Modelle

Mit den folgenden Schritten kann ein Repository-Provider eine vollständige Unterstützung für logische Modelle bereitstellen:

  1. Die entsprechenden Repository-Operationen werden in Elementen ergänzt, die ResourceMapping übernehmen.
  2. Es wird sichergestellt, dass für Ressourcenzuordnungen ausgeführte Operationen alle entsprechenden Modellelemente und Ressourcen enthalten. Hierfür wird eine Schnittstelle ISynchronizationScope und eine unterstützende API verwendet.
  3. Über die Schnittstelle IMergeContext und die unterstützende API wird es Modellprovidern ermöglicht, an automatischen Mischvorgängen teilzunehmen.
  4. Durch die Verwendung von 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.
  5. Der Zugriff auf das Protokoll der Arbeitsbereichsdateien wird über die API IFileHistoryProvider ermöglicht.
  6. Der Zugriff auf ferne Konfigurationen wird unter Verwendung der Dateisystem-API von Eclipse im Plug-in org.eclipse.core.filesystem ermöglicht. Links zu diesen Arbeitsbereichsprojekten werden über ProjectSetCapability hergestellt.
  7. Die Dekoration logischer Modellelemente wird durch die Bereitstellung einer Funktion 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.

Ressourcenzuordnungen durch Aktionen ergänzen

Basis-API für Ressourcenzuordnung

Die API für die Ressourcenzuordnung besteht aus den folgenden Klassen:

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.

Ressourcenzuordnungen und Objektergänzungen

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:

  1. Alle Elemente objectContribution des Erweiterungspunkts popupMenus müssen in der Datei "plugin.xml" aktualisiert werden und ResourceMapping anstelle von IResource als Ziel angeben (wo dies geeignet ist).
  2. Die Aktionen müssen so aktualisiert werden, dass sie 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.

Operationsbereich

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:

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:

  1. Durch die Bereitstellung von RemoteResourceMappingContext für den Abruf der Ressourcentraversierungen aus den Ressourcenzuordnungen.
  2. Durch das Überschreiben von SynchronizationScopeManager, um den Prozess der Bereichsverwaltung wie erforderlich anzupassen.

Diese beiden Aspekte werden in den folgenden Abschnitten ausführlicher erläutert.

Ferner Ressourcenzuordnungskontext

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.

Unterklassen von "SynchronizationScopeManager" bilden

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:

  1. Der Repository-Provider muss aufgrund einer bestimmten Beziehung auf Repository-Ebene (z. B. ein Änderungsset) zusätzliche Ressourcen aufnehmen. Dies kann durch das Überschreiben der Methode adjustInputTraversals(ResourceTraversal[]) erreicht werden.
  2. Die Synchronisierung hat einen längeren Lebenszyklus (z. B. bei der Sicht "Synchronisieren" im Vergleich zum Dialog) und muss auf Bereichsänderungen reagieren können. Die Schnittstelle 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.

Modellbasierte Mischvorgänge

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.

  1. Die API, mit der der Synchronisationsstatus der am Mischvorgang beteiligten Ressourcen beschrieben wird.
  2. Die API, mit deren Hilfe Modellprovider Modellelemente mischen können.
Diese beiden APIs sind in den folgenden Abschnitten beschrieben.

API für die Beschreibung des Synchronisationsstatus'

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.

API für Modellmischvorgänge

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.

Modellinhalt in Teamanzeigefunktionen

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:

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:

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>

Dateiprotokoll

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:

Projektsetfunktion

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.

Modellelemente mit Dekoratoren versehen

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.