Cuando el núcleo de la plataforma está en ejecución y el conector de recursos está activo, el área de trabajo se representa mediante una instancia de IWorkspace, que proporciona protocolo para acceder a los recursos que contiene. Una instancia de IWorkspace representa un conjunto de archivos y directorios asociados en el sistema de archivos local. Se puede acceder al área de trabajo desde la clase de conector de recursos en org.eclipse.core.resources.
ResourcesPlugin.getWorkspace();
Cuando el conector de recursos no está en ejecución, el área de trabajo sólo existe en el sistema de archivos local y el usuario la ve y manipula mediante herramientas estándar basadas en el archivo. A medida que se explica la API de conector de recursos, se mostrará el aspecto del área de trabajo en el disco.
Cuando instaló el SDK de la plataforma, descomprimió los archivos en un directorio que eligió para tal fin. Este directorio es el directorio raíz de la plataforma y contiene el directorio plugins, entre otros. Dentro del directorio raíz de la plataforma, existe el directorio workspace, que se utiliza para mantener los recursos que la plataforma ha creado y manipulado. Si mira el directorio workspace, verá subdirectorios diferentes para cada proyecto que existe en el área de trabajo. En estos subdirectorios se encuentran las carpetas y los archivos que cada proyecto contiene.
Si el SDK del ejemplo se instaló en c:\MySDK, el directorio c:\MySDK\workspace contendrá subdirectorios cuyos nombres, MyWeb y MyServlet, se asigna después del proyecto del área de trabajo. Estos directorios son los directorios del contenido del proyecto. Los directorios de contenido los crea la plataforma cuando el usuario crea un proyecto.
Dentro de cada directorio están los archivos y carpetas del proyecto, dispuestos exactamente igual que en el árbol de recursos del área de trabajo. Todos los nombres de archivo coinciden, y el contenido de los archivos es el mismo tanto si se accede del sistema de archivo como del área de trabajo. Esto no supone ninguna novedad.
C:\MySDK\workspace (directorio raíz del área de trabajo)
.metadata\ (directorio de los metadatos de la plataforma
MyWeb\ (directorio del contenido del proyecto para MyWeb)
index.html
images\
logo.gif
MyServlet\ (directorio de contenido del proyecto para MyServlet)
src\
main.java
bin\
main.class
main$$1.class
La plataforma tiene un directorio .metadata específico para mantener información interna. El directorio .metadata podría compararse con una "caja negra". La información importante sobre la estructura del área de trabajo, como las referencias del proyecto o las propiedades de los recursos, se almacena en la parte de los metadatos del área de trabajo y sólo se debe acceder a ella mediante herramientas a través de la API. Estos archivos no deben editarse ni manipulase nunca utilizando la API del sistema de archivos genérico.
Aparte de para el directorio .metadata, las carpetas y archivos del directorio de espacio de trabajo también resultan útiles para otras herramientas. Los archivos y las carpetas pueden manipularse mediante herramientas no integradas, como editores de texto y programas de utilidad del sistema de archivos. El único aspecto es que el usuario debe actuar con precaución al editar estos archivos tanto en el entorno de trabajo como externamente. (Esto no es diferente a cuando un usuario edita un archivo utilizando dos herramientas autónomas e independientes.) El entorno de trabajo proporciona operaciones de renovación para reconciliar la vista de recursos del entorno de trabajo con el estado real del sistema de archivos.
La API de recursos permite manipular este árbol de recursos en el código. Aquí se mostrarán algunos segmentos de código para tener una visión rápida de cómo funciona la API de recursos. La API de recursos está definida en una serie de interfaces de org.eclipse.core.resources. Existen interfaces para todos los tipos de recursos, comoIProject, IFolder y IFile. El protocolo común extensivo está definido en IResource. También se utiliza la interfaz IPath de org.eclipse.core.runtime,que representa vías de acceso segmentadas, como las vía de acceso de recursos o del sistema de archivos.
La manipulación de recursos es muy parecido a manipular archivos utilizando java.io.File. La API se basa en manejadores. Cuando utiliza una API, como getProject o getFolder, devuelve un manejador al recurso. No existe ninguna garantía ni ningún requisito por el que el recurso exista hasta que intenta realizar alguna acción con el manejador. Si espera que exista un recurso, puede utilizar el protocolo exists() para asegurarse de que existe.
Para navegar al área de trabajo desde un conector, se debe obtener en primer lugar IWorkspaceRoot, que representa el nivel superior de la jerarquía de recursos en el área de trabajo.
IWorkspaceRoot myWorkspaceRoot = ResourcesPlugin.getWorkspace().getRoot();
En cuanto se dispone de un directorio raíz de área de trabajo se puede acceder a los proyectos de dicha área.
IProject myWebProject = myWorkspaceRoot.getProject("MyWeb");
// abrir si es necesario
if (myWebProject.exists() && !myWebProject.isOpen())
myWebProject.open(null);
Para poder manipular un proyecto es preciso abrirlo. Al abrir un proyecto se lee la estructura del proyecto desde el disco y se crea la representación de objeto en memoria del árbol de recursos del proyecto. La apertura de un proyecto es una operación explícita, ya que cada proyecto abierto utiliza memoria para representar el árbol de recursos internamente y abrir participaciones de proyectos en varios eventos de ciclo de vida de recursos (como la construcción) que pueden durar bastante tiempo. Generalmente, no se puede acceder a los proyectos cerrados y aparecerán vacíos aunque los recursos sigan estando presentes en el sistema de archivos.
Observará que muchos de estos ejemplos de recursos pasan un parámetro nulo cuando se manipulan recursos. Muchas operaciones de recursos pueden ser lo suficientemente largas como para garantizar el informe de progreso y su cancelación por parte del usuario. Si el código tiene una interfaz de usuario, se suele pasar un IProgressMonitor, que permite al conector de recursos informar del progreso a medida que se manipula el recurso y permite al usuario cancelar la operación si lo desea. De momento, sólo se pasa null, que indica que no hay supervisión del progreso.
En cuanto se tiene un proyecto abierto, se puede acceder a sus carpetas y archivos, así como crear carpetas y archivos adicionales. En el ejemplo siguiente, se crea un archivo de recursos a partir del contenido de un archivo externo ubicado fuera del área de trabajo.
IFolder imagesFolder = myWebProject.getFolder("images");
if (imagesFolder.exists()) {
// crear un archivo nuevo
IFile newLogo = imagesFolder.getFile("newLogo.gif");
FileInputStream fileStream = new FileInputStream(
"c:/MyOtherData/newLogo.gif");
newLogo.create(fileStream, false, null);
fileStream.close();
}
En el ejemplo anterior, la primera línea obtiene un manejador para la carpeta de imágenes. Se debe comprobar que la carpeta existe antes de poder utilizarla. De esta manera, cuando se obtiene el archivo newLogo, el manejador no representa un archivo real hasta que se crea el archivo en la última línea. En este ejemplo, se crea el archivo rellenándolo con el contenido de logo.gif.
El siguiente segmento es parecido al anterior, excepto que copia el archivonewLogo del logotipo original en lugar de crear uno nuevo a partir de su contenido.
IFile logo = imagesFolder.getFile("logo.gif");
if (logo.exists()) {
IPath newLogoPath = new Path("newLogo.gif");
logo.copy(newLogoPath,
false, null);
IFile newLogo = imagesFolder.getFile("newLogo.gif");
...
}
Por último, se creará otra carpeta de imágenes y se moverá el archivo creado recientemente a ella. En el momento de mover el archivo se le asigna un nombre.
...
IFolder newImagesFolder = myWebProject.getFolder("newimages");
newImagesFolder.create(false, true, null);
IPath renamedPath = newImagesFolder.getFullPath().append("renamedLogo.gif");
newLogo.move(renamedPath, false, null);
IFile renamedLogo = newImagesFolder.getFile("renamedLogo.gif");
La mayoría de los métodos API del recurso incluyen un distintivo force booleano que especifica si se actualizarán los recursos que no están sincronizados con los archivos correspondientes en el sistema de archivos local. Consulte IResource para obtener más información.
En el árbol de recursos de ejemplo, se ha presupuesto que todos los directorios de contenido del proyecto están en el directorio workspace debajo del directorio raíz de la plataforma (C:\MySDK\workspace). Ésta es la configuración por omisión para proyectos. Sin embargo, el directorio del contenido de un proyecto puede redistribuirse a cualquier directorio arbitrario en el sistema de archivos, tal vez en una unidad de discos diferentes.
La posibilidad de correlacionar la ubicación de un proyecto independiente de otros proyectos permite al usuario almacenar el contenido de un proyecto en un lugar significativo para el proyecto y el equipo del proyecto. El directorio de contenido de un proyecto debe considerarse "abierto al descubierto". Esto significa que los usuarios pueden crear, modificar y eliminar recursos utilizando el entorno de trabajo y conectores o utilizando directamente un sistema de archivos basado en herramientas y editores.
Los nombres de vías de acceso de recursos no son vías de acceso completas del sistema de archivos.Las vías de acceso de recursos siempre se basan en la ubicación del proyecto (generalmente el directorio workspace). Para obtener la vía de acceso completa del sistema de archivos para un recurso, debe localizarlo utilizando IResource.getLocation().
Puede determinar la ubicación del sistema de archivos de un recurso concreto localizándolo mediante getLocation(). Sin embargo, no puede utilizar IProjectDescription.setLocation para cambiar su ubicación, porque ese método sólo es un establecedor de establecimiento para una estructura de datos.
Al utilizar la API de recursos para modificar el árbol de recursos del área de trabajo, los archivos se modifican en el sistema de archivos además de actualizar los objetos de recursos. ¿Qué ocurre con los cambios en archivos de recursos que tienen lugar fuera de la API de la plataforma?
Los cambios externos en los recursos no se reflejarán en el área de trabajo ni en los objetos de recursos hasta que los detecte el conector de recursos. Los clientes pueden utilizar una API de recursos para reconciliar el área de trabajo y los objetos de recursos con el sistema de archivos local de manera pausada y sin la intervención del usuario. El usuario siempre puede forzar una renovación de manera explícita en la vista del navegador de recursos del entorno de trabajo.
Nota: La mayoría de los métodos de las API de recursos incluyen un parámetro force que especifica cómo deben manejarse los recursos que no están sincronizados con el sistema de archivos. El manual de consulta de API para cada método proporciona información específica sobre este parámetro. Los métodos adicionales en la API permiten el control programático de la renovación del sistema de archivos, como IResource.refreshLocal(int depth, IProgressMonitor monitor). Consulte IResource para obtener información sobre su utilización correcta y coste.