Soporte de equipo para integración de modelos lógicos
Al describir el soporte de equipo para integración de modelos lógicos, existen dos
puntos de vista interesantes:
- Proveedor de repositorio: un proveedor de repositorio es la conexión
entre el espacio de trabajo local y un repositorio remoto. Los detalles del soporte de
modelos lógicos desde el punto de vista de un proveedor de repositorio se encuentran en
el Mapa de ruta de repositorios para integración de modelos
lógicos.
- Proveedor de modelo: un proveedor de modelo es el conjunto de
herramientas que permite al usuario trabajar con los elementos de modelo almacenados en
los recursos del espacio de trabajo local. Los detalles acerca de cómo pueden aprovechar
este soporte los proveedores de modelos se encuentran en el
Mapa de ruta de modelos para integración de modelos lógicos.
Los puntos siguientes resumen las características suministradas por el soporte de
modelos lógicos de equipo.
- Mantenimiento de la coherencia del espacio de trabajo: las operaciones realizadas
directamente sobre los recursos pueden tener efectos colaterales no deseados sobre los
elementos de modelo en los que persisten o con los que están asociados duchos recursos. Los
clientes pueden utilizar ResourceChangeValidator para comprobar que los cambios
realizados en los recursos no tendrán efectos colaterales no deseados en los modelos,
mientras que los modelos pueden implementar el método ModelProvider#validateChange para
validar un cambio de recurso.
- Operaciones y decoraciones de equipo: siempre ha sido posible conseguir que las
operaciones y decoraciones de equipo aparezcan en elementos de modelo que tienen una
relación de uno a uno adaptando el elemento de modelo al IResource correspondiente.
Ahora es posible conseguir que las operaciones y decoraciones aparezcan en elementos
de modelo que tienen relaciones más complejas con los recursos adaptando un elemento de
modelo a una ResourceMapping.
- Fusiones semánticas de elementos de modelo: los proveedores de modelos pueden
participar en fusiones autónomas asociando un IStorageMerger con un tipo de archivo
determinado, si existe una correspondencia de uno a uno entre los elementos de modelo y
los recursos. En relaciones más complejas, los proveedores de modelos pueden adaptar su
ModelProvider a un IResourceMappingMerger para tener acceso al contenido completo de la
operación de fusión.
- Participación de modelos en visores de equipo: los visores de equipo pueden ahora
utilizar la infraestructura de Navegador común. Mediante la ampliación de un punto de
extensión de Navegador común y un punto de extensión de Equipo, y suministrando un
proveedor de contenido y uno de etiquetas, un proveedor de modelo puede aparecer en las
vistas de equipo. Con algunos pasos adicionales, también es posible suministrar soporte
de Vista previa de fusión para un modelo.
- Descubrimiento remoto: los proveedores de modelos pueden participar en el
Descubrimiento remoto mediante la utilización de la clase ProjectSetCapability de
equipo para obtener un URI desde las entradas de conjunto de proyectos. A continuación,
puede utilizarse este URI con la API de sistema de archivos de Eclipse para acceder a
contenido remoto.
- Historial de modelos: los proveedores de modelos pueden acceder a un historial de
archivo individual mediante la API FileHistory y presentar un historial de modelos según
deseen en una página Historial personalizada que se visualizará en la vista Historial.