Схема хранилища для интеграции логической модели

Для предоставления полной поддержки логических моделей, класс хранилища может выполнить следующие действия:

  1. Добавить подходящие операции хранилища к элементам, которые приспосабливают их к ResourceMapping.
  2. С помощью ISynchronizationScope и поддерживающего API обеспечить, чтобы выполняемые над записями преобразования ресурсов операции включали в себя все подходящие элементы модели и ресурсы.
  3. С помощью интерфейса IMergeContext и поддерживающего API позволить поставщикам модели участвовать в консольном слиянии.
  4. С помощью teamContentProviders для моделей, вовлеченных в слияние, позволить поставщикам модели участвовать в предварительном просмотре слияния. Класс ModelSynchronizeParticipant предоставлен для помощи в управлении взаимоотношениями между содержимым модели, контекстом слияния и структурой Сравнение.
  5. С помощью API IFileHistoryProvider обеспечить доступ к хронологии файлов рабочей области.
  6. С помощью API файловой системы Eclipse в модуле org.eclipse.core.filesystem предоставить доступ к удаленным конфигурациям и связать их с проектами рабочей области посредством ProjectSetCapability.
  7. Обеспечить поддержку значка оформления элемента логической модели, предоставив Subscriber рабочей области для использования в API SynchronizationStateTester.

В следующих разделах описан каждый из этих пунктов более подробно. Модуль org.eclipse.team.examples.filesystem содержит пример, иллюстрирующий несколько этих пунктов. Проект можно извлечь из хранилища CVS и при изучении этого материала пользоваться им как справочником. Оговорка: Исходный код модуля примера может измениться в любое время. Для получения копии, соответствующей этому примеру, следует выбрать проект по версии (3.2) (скорее всего, R3_2) или по дате: 28 июня 2006 г.

Действия добавления к записям преобразования ресурсов

API основного преобразования ресурсов

API преобразования ресурсов состоит из следующих классов:

Существует два типа модулей, которые относятся к преобразованиям ресурсов. Те, которые обеспечивают модель, состоящую из ресурсов в рабочей области или хранящуюся в них, и те, которые выполняют операции над ресурсами. Первый случай будет описан в схеме модели, а второй - в следующем разделе.

Преобразования ресурсов и дополнения объектов

Модули, которые дополняют расширения к настраиваемым точкам расширения, должны произвести два изменения для поддержки новых API ResourceMapping:

  1. Изменить все objectContributions точки расширения popupMenus в файле plugin.xml таким образом, чтобы они указывали на ResourceMapping вместо IResource (там где это применимо).
  2. Изменить их действия на работу с ResourceMapping вместо IResource и учесть ограничение глубины для прохождений.

Модули, которые добавляют дополнения объектов к IResource, могут теперь вместо этого добавлять их к ResourceMapping, если действие может быть применено к нескольким ресурсам. Следующий фрагмент кода XML дополняет действие меню для объектов, приспосабливаемых к преобразованиям ресурса:

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

Дополнения к ResourceMapping будут автоматически применены к объектам, приспособленным к IResource. Эта временная связь управляется рабочей средой. Фильтрация дополнений к преобразованиям ресурсов может быть выполнена с помощью выражений подключения. Выражение для фильтрации по постоянному свойству проекта было добавлено для того, чтобы позволить классам хранилища показывать свои меню для проектов, соответствующих их хранилищам.

Действия, дополненные к классу ResourceMapping, будут даны в качестве выбора, состоящего из одного или нескольких ResourceMappings. Действия ответственны за трансляцию преобразования ресурса в набор ресурсов, над которыми они должны производится. Это может быть сделано с помощью вызова getTraversals для получения прохождений преобразований. Прохождения используются для того, чтобы позволить клиентам оптимизировать операции на основании глубины прохождения ресурсов. Клиент может совершить прохождение ресурса вручную или использовать ресурс и глубину как вход для операции, которой действие передало управление. Например, если пользователь выполняет обновление CVS в пакете java, и преобразование ресурса пакета java указывает на папку глубины 1, то CVS выполнит соответствующую команду ("cvs update -l") для поверхностного изменения папки, которую представляет пакет.

Хотя возможно получить набор прохождений непосредственно из выбранных преобразований ресурсов, существуют взаимоотношения модели (или взаимоотношения хранилища), которые могут требовать включение дополнительных ресурсов или элементов модели в операцию. В следующем разделе описано, как обеспечить, чтобы все требуемые ресурсы были включены в операцию.

Область действия операции

Для коллективных операций, выбранные преобразования должны быть транслированы в набор преобразований, над которыми совершаются эти операции. Этот процесс включает в себя просмотр всех поставщиков моделей, для того чтобы убедится в том, что они включены в операции над ресурсами, соответствующие их правилам подключения. Термин, который используется для описания набора ресурсов, над которыми выполняется операция, - это область действия операции. Следующий API предоставлен для этого:

Метод initialize(IProgressMonitor) класса SynchronizationScopeManager управляет всем процессом трансляции входного набора преобразований ресурсов в полный набор преобразований, над которым выполняется операция, а также полный набор прохождений, охватывающих эти преобразования. Класс хранилища может приспособить процесс с помощью:

  1. Предоставления RemoteResourceMappingContext для использования при получении прохождений ресурсов из преобразований ресурсов.
  2. Переопределения SynchronizationScopeManager для подгонки процесса управления областью действия.

В следующих двух разделах описан каждый из этих пунктов более подробно.

Контекст преобразования удаленного ресурса

Для того чтобы гарантировать, что все необходимые ресурсы включены в коллективную операцию, поставщик модели должен иметь возможность получать информацию о состоянии одного или нескольких ресурсов в хранилище. Для некоторых моделей это может не понадобиться. Например, пакет java - контейнер, осматривающий глубину 1, независимо от удаленного состояния модели. При этом, класс хранилища может легко определить, что исходящие удаления должны быть включены при фиксации, или что входящие добавления должны быть включены при изменении. Однако, ресурсы, составляющие несколько логических моделей, могут со временем меняться. Например, ресурсы, составляющие элемент модели, могут зависеть от содержимого файла манифеста (или некоторого другого подобного механизма). Для того чтобы преобразование ресурса возвращало правильное прохождение, оно должно иметь доступ к удаленному содержимому файла манифеста (если оно отличается от локального содержимого), чтобы видеть, существуют ли дополнительные ресурсы, которые должны быть включены. Эти дополнительные ресурсы могут не существовать в рабочей области, но класс хранилища должен знать, как обеспечить, чтобы они там были, когда выполняется выбранное действие.

Для поддержки этих более сложных моделей RemoteResourceMappingContext может быть передан в метод ResourceMapping#getTraversals. Когда предоставляется контекст, преобразование может использовать его, чтобы все необходимые ресурсы были включены в прохождение. Если контекст не предоставлен, преобразование может считать, что интересно только локальное состояние.

Контекст преобразования удаленного ресурса предоставляет три основных вопроса:

Ответ на первый вопрос зависит от типа выполняемой операции. Обычно, обновления и слияния трехсторонни, в то время как операции сравнения и замены (по крайней мере для CVS) двухсторонни.

API Коллективная работа Eclipse включает в себя класс Subscriber, который определяет API для предоставления и синхронизации состояния между локальной рабочей областью и удаленным сервером. Предоставленный SubscriberResourceMappingContext использует Подписчик для доступа к необходимому удаленному состоянию. Клиенты, имеющие Подписчик, не требуют дополнительных действий, чтобы получить контекст преобразования ресурса.

Наследование SynchronizationScopeManager

Класс SynchronizationScopeManager может быть унаследован для генерации области действия и процесса управления. Две главных причины наследования администратора области действия состоят в следующем:

  1. Класс хранилища требует включения дополнительных ресурсов, соответствующих некоторой взаимосвязи уровня хранилища (например, набору изменений). Это может быть выполнено с помощью переопределения метода adjustInputTraversals(ResourceTraversal[]).
  2. Синхронизация имеет длинный жизненный цикл (например, синхронизация панели и окна диалога) и требует возможности реагировать на изменения области действия. Интерфейс ISynchronizationScopeParticipant определяет API, который поставщики модели могут использовать для участия в процессе управления областью действия. Класс SubscriberScopeManager - это подкласс класса SynchronizationScopeManager на основе Подписчика, который вовлекает участников в процесс управления областью действия. Рабочие наборы являются примером того, почему необходимы процессы этого типа. Если рабочим набором является одно из преобразований ресурса в области действия, то набор прохождений, охваченных областью действия, должен увеличиваться при добавлении ресурсов к рабочему набору.

Слияние на основе модели

Главный тип операции хранилища, который требует участия модели, - это слияние. Во многих случаях, моделям нужно участвовать только на уровне файла. Для этого предназначен API IStorageMerger, который позволяет поставщикам модели добавлять участников слияния для слияния файлов с определенным расширением или типом содержимого. Однако, в некоторых случаях, моделям может понадобиться дополнительный контекст для правильного участия в слиянии. Для этого существуют API IResourceMappingMerger и IMergeContext.

Операции слияния инициируются действиями, связанными с классом хранилища. Однако, когда пользователь запрашивает операцию типа слияния, классу хранилища необходимо вовлечь в процесс слияния поставщиков моделей, для того чтобы обеспечить сохранность моделей.

Существует две основных части API класса хранилища, связанных с поддержкой слияния на основе модели.

  1. API для описания состояния синхронизации ресурсов, вовлеченных в слияние.
  2. API, который позволяет поставщикам моделей осуществить слияние элементов моделей.
В следующих разделах описаны эти две части.

API для описания состояния синхронизации

Важным аспектом слияния на основе модели является API, используемый для описания состояния синхронизации вовлеченных ресурсов. Для описания состояния синхронизации служат следующие интерфейсы:

Абстрактные классы предоставляются для всех этих интерфейсов с соглашением, что имена классов соответствуют именам интерфейсов без префикса "I". Классы хранилища должны переопределить единственный класс - ResourceDiff, так чтобы могли быть предоставлены подходящие ревизии файла, исходная и окончательная.

API для слияния модели

Интерфейс IMergeContext расширяет контекст синхронизации с помощью дополнительных методов, поддерживающих слияние. Ответные методы существуют для:

Предоставлен абстрактный класс MergeContext, содержащий реализации по умолчанию для большинства функций слияния, а также использующий IStorageMerger для выполнения трехсторонних слияний. Предоставлен также класс SubscriberMergeContext, который управляет заполнением и поддержкой описания состояния синхронизации, связанного с контекстом слияния.

Предоставлен класс операции ModelMergeOperation, который использует API IResourceMappingMerger для выполнения операции слияния на основе модели. Подклассы должны переопределить метод initializeContext(IProgressMonitor) для возвращения контекста слияния. Операция использует этот контекст, пытаясь произвести консольное слияние на основе модели. Если существуют конфликты, показывается окно предварительного просмотра для подкласса. Как мы увидим в следующем разделе, существует ModelParticipantMergeOperation, предоставляющий возможность предварительного просмотра с помощью ModelSynchronizeParticipant.

Содержимое модели в коллективных программах просмотра

В коллективных операциях предоставляется поддержка для просмотра логических моделей с помощью структуры Общего навигатора, который был введен в Eclipse 3.2. Логические модели могут связывать расширение содержимого с поставщиком модели с помощью точки расширения org.eclipse.team.ui.teamContentProvider. Классы коллективной работы получают доступ к этим поставщикам содержимого посредством ITeamContentProviderManager.

Классам коллективной работы может понадобиться показать логические модели в следующих ситуациях:

ModelSynchronizeParticipant обеспечивает интеграцию в панель Синхронизировать или любой контейнер, который может показать iSynchronizePages. Участник использует и предварительно существующие группы функций участника синхронизации, и группы функций Общего навигатора, для того чтобы позволить классам коллективной работы и моделям составить панель инструментов, контекстное меню и другие аспекты предварительного просмотра слияния. ModelSynchronizeParticipant обеспечивает следующее:

Ниже приведена справочная таблица шагов по настройке участника синхронизации модели для определенного класса коллективной работы:

Следующие фрагменты кода XML иллюстрируют способ регистрации класса участника CVS и определения его программы просмотра.

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

Хронология файла

Был добавлен API хронологии файла, который позволяет моделям получать доступ к хронологии файлов. API хронологии файла состоит из следующих интерфейсов:

Вместе с этим API была добавлена панель Хронология. Она позволяет классам коллективной работы показывать их хронологию файла/ресурса на общей панели, а также позволяет моделям показывать хронологию их элементов, которые не соответствуют непосредственно файлам. Панель Хронология - это панель на основе страницы, которая получает страницу для выбранного элемента следующим образом:

Возможность установки проекта

К ProjectSetCapability были добавлены методы для поддержки трансляции между строкой указателя, используемой для идентификации соответствия между проектом и удаленным содержимым, и URI, которые идентифицируют схему файловой системы с помощью точки расширения org.eclipse.core.filesystem.filesystems. Классы коллективной работы могут по выбору предоставлять поддержку этого, для того чтобы позволить логическим моделям выполнять удаленный просмотр и загрузку проекта.

Оформление элементов модели

Классы коллективной работы могут оформить элементы модели, переделав их упрощенный оформитель для работы с преобразованиями ресурсов таким же образом, как дополнения объекта переделываются для работы с преобразованиями ресурсов. Однако, один аспект оформления элемента логической модели является проблематичным. Если элемент модели не имеет преобразования один-к-одному по отношению к ресурсу, то он не может получить обновление метки при соответствующем изменении ресурса.

Для решения этой проблемы был введен ITeamStateProvider, чтобы предоставить поставщикам модели доступ к изменениям состояния, которые могут повлиять на оформление. Кроме того, панели модели могут использовать SynchronizationStateTester для определения того, когда необходимо изменение меток элементов логической модели. Этот API зависит от интерфейса ITeamStateProvider при определении того, когда состояние ресурса меняется и может быть передано оформителю как часть IDecorationContext.