Si tiene previsto suministrar soporte de sincronización y no dispone de un mecanismo para gestionar el estado de sincronización, esta sección describe cómo implementar un Suscriptor desde cero. Esto significa que no existe ninguna infraestructura de sincronización e ilustra la utilización de algunas API suministradas para mantener el estado de sincronización.
En el resto de estos ejemplos, se utilizará un ejemplo de ejecución. El código fuente puede encontrarse en el paquete del proveedor del sistema de archivos del conector org.eclipse.team.examples.filesystem. Debe reservar el proyecto en el repositorio CVS y utilizarlo como referencia durante la lectura de esta guía de aprendizaje.
Este primer ejemplo presupone que no existe ninguna infraestructura para mantener el estado de sincronización del área de trabajo local. Al implementar un suscriptor desde cero, puede utilizar algunas API adicionales suministradas en el conector org.eclipse.team.core. El paquete org.eclipse.team.core.variants contiene dos subclases de Subscriber que pueden utilizarse para simplificar la implementación. La primera es ResourceVariantTreeSubscriber , que se describirá más adelante en el segundo ejemplo. La segunda es una subclase de la primera: ThreeWaySubscriber. Esta implementación del suscriptor proporciona varias clases útiles para gestionar el estado de sincronización de un área de trabajo local. Si no dispone de ninguna infraestructura, este es un buen lugar para empezar.
La implementación de un suscriptor desde cero se ilustrará mediante el ejemplo de sistema de archivos disponible en el conector org.eclipse.team.examples.filesystem. El código de la siguiente descripción es el mínimo posible, ya que está disponible en el repositorio CVS de Eclipse. Aunque técnicamente no es un suscriptor de tres vías, el ejemplo de sistema de archivos puede utilizar adecuadamente esta infraestructura. Los conectores FTP y WebDav también se han construido mediante esta infraestructura.
Para el ejemplo de sistema de archivos, ya disponíamos de una implementación de un RepositoryProvider que asociaba un proyecto local con una ubicación del sistema de archivos en la que se reflejaba el contenido local. FileSystemSubscriber se creó como subclase de ThreeWaySubscriber para poder utilizar un ThreeWaySynchronizer destinado a gestionar el estado de sincronización del área de trabajo. Las subclases de esta clase deben hacer lo siguiente:
Además de la implementación del suscriptor, se han modificado las operaciones get y put del proveedor del sistema de archivos para actualizar el estado de sincronización de ThreeWaySynchronizer. Las operaciones se implementan en la clase org.eclipse.team.examples.filesystem.FileSystemOperations.
ThreeWaySynchronizer gestiona el estado de sincronización entre el área de trabajo local y una ubicación remota. Almacena en antememoria y hace que persistan las indicaciones de la hora local, base y remota para dar soporte al cálculo eficaz del estado de sincronización de un recurso. También activa notificaciones de cambio en los escuchas registrados. ThreeWaySubscriber convierte estos eventos de cambio al formato correcto que debe enviarse a los escuchas registrados en el suscriptor.
ThreeWaySynchronizer utiliza las normas de planificación y bloqueos del núcleo para garantizar la seguridad de las hebras y suministrar agrupación por lotes de la notificación de cambios.
ThreeWayRemoteTree es una subclase de ResourceVariantTree adaptada a ThreeWaySubscriber. Los clientes deben alterarla temporalmente para suministrar el mecanismo para extraer el estado remoto del servidor. ResourceVariantTree se describe con más detalle en el próximo ejemplo.
CachedResourceVariant es una implementación parcial de IResourceVariant que almacena en antememoria el contenido extraído durante un período de tiempo (actualmente 1 hora). Esto resulta de utilidad, ya que puede accederse al contenido varias veces en un período de tiempo corto (por ejemplo, para determinar el estado de sincronización y visualizar el contenido en un editor de comparación). Las subclases deben seguir proporcionando el identificador de contenido exclusivo junto con la matriz de bytes que puede persistir a fin de recrear el handle de variante de recurso.
Es posible que muchos proveedores de repositorios cuenten ya con un mecanismo para gestionar su estado de sincronización (por ejemplo, si tienen conectores existentes). ResourceVariantTreeSubscriber y sus clases relacionadas proporcionan la capacidad de construir encima de una infraestructura de sincronización existente. Por ejemplo, esta es la superclase de todos los suscriptores de CVS.
Como se ha indicado en el ejemplo anterior, ThreeWaySubscriber es una subclase de ResourceVariantTreeSubscriber que proporciona sincronización del área de trabajo local mediante ThreeWaySynchronizer. Las subclases de ResourceVariantTreeSubscriber deben proporcionar:
Subclases de ResourceVariantTree (o AbstractResourceVariantTree) que proporcionen el comportamiento para cruzar y renovar las variantes de recurso remoto y, para los suscriptores que soportan comparaciones de tres vías, las variantes de recurso base.
Las demás posibilidades del suscriptor se implementan mediante los siguientes recursos.
ResourceVariantTree es una implementación concreta de IResourceVariantTree que proporciona lo siguiente:
Las subclases deben implementar lo siguiente:
Se suministran implementaciones concretas de ResourceVariantByteStore que hacen que los bytes persistan en las invocaciones del entorno de trabajo (PersistantResourceVariantByteStore) o que los bytes se almacenen en antememoria sólo para la sesión actual (SessionResourceVariantByteStore). Sin embargo, la construcción de un suscriptor encima de una sincronización del área de trabajo existente requerirá generalmente la implementación de subclases ResourceVariantByteStore que actúen como interfaz con el sincronizador subyacente. Por ejemplo, ThreeWayRemoteTree utiliza una implementación de almacén de bytes que almacena los bytes remotos en ThreeWaySynchronizer.
La creación de handles de variante de recurso para este ejemplo no difiere del ejemplo anterior, excepto que los handles se solicitan desde una instancia del árbol de variantes de recurso en lugar de desde el suscriptor.