Un proyecto puede contener recursos que no se encuentren dentro del directorio del proyecto en el sistema de archivos local. Estos recursos se conocen como recursos enlazados.
Los recursos enlazados pueden plantear determinados problemas a los proveedores de depósitos que operan directamente con el sistema de archivos. Esto es consecuencia del hecho de que los recursos enlazados por diseño no existen en el árbol de directorios inmediato del proyecto en el sistema de archivos.
Los proveedores que presenten las siguientes características pueden resultar afectados por los recursos enlazados:
En el primer caso, supongamos que el usuario toma un recurso enlazado e intenta realizar en él una operación del proveedor. Dado que el proveedor llama a un cliente de línea de mandatos, podemos suponer que el proveedor realiza alguna acción equivalente a llamar en primer lugar a IResource.getLocation().toOSString(), suministrando la ubicación del sistema de archivos resultante como argumento al programa de línea de mandatos. Si el recurso en cuestión es un recurso enlazado, esta acción producirá un archivo/carpeta situado fuera del árbol de directorios del proyecto. No todos los clientes de línea de mandatos están preparados para esperar y manejar este caso. En pocas palabras, si el proveedor obtiene la ubicación de un recurso en el sistema de archivos, probablemente requerirá un trabajo adicional para manejar los recursos enlazados.
El segundo caso es bastante parecido, en el sentido de que se realiza una suposición implícita de que la estructura de los recursos del proyecto es 1:1 con respecto a los archivos y carpetas del sistema de archivos. En general, un proveedor puede experimentar problemas si mezcla operaciones IResource y java.io.File. Por ejemplo, en el caso de los enlaces, el padre de IFile no es el mismo que el padre de java.io.File, y el código que presupone que son los mismos fallará.
Era importante que la introducción de recursos enlazados no implicara la interrupción inadvertida de los proveedores existentes. Específicamente, la preocupación concernía a los proveedores que presuponían razonablemente que la estructura del sistema de archivos local reflejaba la estructura del proyecto. En consecuencia, los recursos enlazados no pueden añadirse por omisión a los proyectos correlacionados con un proveedor de este tipo. Además, los proyectos que contienen recursos enlazados no pueden compartirse por omisión con ese proveedor.
Para ser "amigo de los enlaces", un proveedor debe permitir que los proyectos con recursos enlazados estén controlados por versión, pero puede impedir el control de versiones de los recursos enlazados en sí.
Una solución considerablemente más compleja consiste en permitir la creación de versiones de los recursos enlazados reales, pero no es aconsejable, ya que presenta escenarios complejos (por ejemplo, el archivo podría estar ya bajo el control de versiones de un árbol de proyectos diferente de otro proveedor). Por tanto, nuestra recomendación es dar soporte a los proyectos con control de versiones que contengan recursos enlazados sin control de versiones.
Las implementaciones de proveedor de depósitos pueden actualizarse para dar soporte a los recursos enlazados alterando temporalmente el método RepositoryProvider.canHandleLinkedResources() para que devuelva true. Una vez realizada esta acción, los recursos enlazados podrán existir en proyectos compartidos con ese proveedor de depósitos. Sin embargo, el proveedor de depósitos debe realizar algunas operaciones para asegurarse de que los recursos enlazados se manejan adecuadamente. Como se ha indicado anteriormente, se aconseja encarecidamente que los proveedores de depósitos ignoren todos los recursos enlazados. Esto significa que los recursos enlazados (y sus hijos) deben excluirse de las acciones soportadas por el proveedor de depósitos. Además, el proveedor de depósitos debe utilizar el comportamiento de movimiento y supresión por omisión para los recursos enlazados si la implementación de proveedor de depósitos altera temporalmente el IMoveDeleteHook por omisión.
Los proveedores de equipo pueden utilizar el método IResource.isLinked() para determinar si un recurso es un enlace. Sin embargo, este método sólo devuelve true para la raíz de un enlace. Puede utilizarse el fragmento de código siguiente para determinar si un recurso es hijo de un enlace.
String linkedParentName = resource.getProjectRelativePath().segment(0); IFolder linkedParent = resource.getProject().getFolder(linkedParentName); boolean isLinked = linkedParent.isLinked();
Los proveedores de depósitos deben pasar por alto los recursos para los que el código anterior devuelva true.