Blog Eclipse

10 consejos para trabajar en equipo con Eclipse

¿Trabajas en equipo con Eclipse y no consigues siempre tener un estatuto claro de las estaciones de trabajo de los desarrolladores? ¿La instalación de una nueva estación te coge mucho tiempo? ¿Tienes preguntas acerca de tu organización de trabajo? ¿Crees que podrías mejorar las cosas?

Este artículo te dará 10 consejos para guiarte en la uniformación de tus estaciones de desarrollo.

1. Instalación de Eclipse

Para bien desarrollar, es esencial utilizar la última versión de Eclipse disponible. Esta versión se puede descargar en el sitio web de Eclipse: https://www.eclipse.org/downloads/

Si la versión de Eclipse descargada no es suficiente (por ejemplo un eclipse Modeling no contiene los webtools o svn) habrá que gestionar las herramientas adicionales. Hay varias maneras de hacerlo:

  • listar en un wiki, los updates sites de la herramientas complementarias para instalar y difundir la información
  • instalar los complementos en un Eclipse recién descargado, y hacer instalar esta versión (gestionar las diferentes plataformas si hay desarrolladores en windows/linux, etc…)
  • proponer un update site interno, que contiene todas las herramientas para instalar

En todos los casos, hay que asegurarse de que cada desarrollador trabaja con las mismas versiones de herramientas.

2. Gestión del workspace

Eclipse gestiona los proyectos en un workspace con los parámetros asociados llamados preferencias.

Cada proyecto tiene sus características en función de los clientes, hay que gestionar un workspace por proyecto.

En el caso del desarrollo en las ramas de mantenimiento, también utilizamos un workspace dedicado a esta rama.

Pasaremos de un workspace a un otro utilizando el comando ‘File->Switch Workspace…’.

Podremos copiar las preferencias de un workspace a otro cuando se crea un nuevo workspace, o importar las preferencias almacenadas en un archivo, después de haber creado el workspace.

3. Configuraciones de Java

En un entorno multi-desarrollador, las máquinas y las configuraciones Java son a menudo diferentes. Para evitar problemas de configuración, hay que establecer algunos parámetros desde el principio.

Los entornos Java se utilizan para que hacer coincidir la versión de Java (J2SE 1.5 por ejemplo) con un JRE o JDK instalado en una estación. Estos entornos se almacenan en el workspace actual. Este es una de las pocas configuraciones manuales que se deba hacer en cada estación de trabajo, las otras pueden ser compartidas guardando las preferencias (ver capítulo 5):

A continuación en los proyectos java (para los plugins sólo se puede elegir entornos), sólo los entornos Java deben ser utilizados y referenciados. No se debe utilizar el JRE actual o un JRE alternativo:

Por lo tanto, si un desarrollador recupera un proyecto por la gestión de configuración del proyecto y tiene por defecto un JDK 1.5, su proyecto estará en error y tendrá que ajustar sus preferencias correctamente.

4. Formateo del código

Otra configuración importante: las normas de formateo del código que hay que compartir entre todos los desarrolladores. Si no se fijan en al principio, y que los archivos se entregan en la gestión de la configuración, esto causará problemas si se comparan con las versiones anteriores.

La configuración, para Java, se encuentra en las páginas de preferencias. Lo ideal es importar un archivo de preferencias común, específico al proyecto y compartido en la red (obtenido la primera vez haciendo un ‘export all’):

Podemos por ejemplo modificar el tamaño predeterminado de la línea (80 columnas) y que ahora es inadaptado, dado el tamaño de las pantallas!

5. Compartir las preferencias del workspace

Al exportar las preferencias del workspace (menú Export -> Preferences), es posible y fácil de compartir las preferencias comunes del proyecto. El archivo .epf creado puede luego importarse en las otras estaciones.

6. Commit de los archivos de gestión de Eclipse

Eclipse almacena en el directorio del proyecto algunos archivos de configuración necesarios para su funcionamiento. Encontramos principalmente:

  • el archivo de .project que contiene las informaciones del proyecto
  • el .classpath si el proyecto es de naturaleza java
  • el .cproject si el proyecto es de C/C++
  • el directorio .settings que contiene las propiedades de los recursos.

Estos archivos deben estar ‘commited’ en la gestión de configuración para encontrarlos en cada puesto de desarrollo.

7. Compartir los launch configuration

Independientemente del tipo de proyecto, los parámetros de lanzamientos de un ‘launch configuration’ se pueden almacenar en un archivo. El acceso al archivo compartido está en la pestaña ‘Common’ de cada launch configuration. Un archivo .launch se almacena en el proyecto y se puede ‘commit’ en la gestión de la configuración. Al seleccionar los menús Run o Debug, los otros desarrolladores podrán acceder directamente a los menús.

8. Gestión del target plateform

Al desarrollar una aplicación RCP, es necesario fijar el target platform del workspace.

Lo mejor es crear un archivo target (New Wizard -> target Definition) en el plugin principal de la aplicación. Este archivo se almacena por supuesto en la gestión de la configuración (CVS, SVN, GIT…).

Para permitir el uso común de los archivos target, no hay que referenciar los archivos en local, sino más bien directamente referenciar los sitios Eclipse, o también un directorio compartido accesible.

Así la pantalla de preferencias de target platform referencia todos los archivos .target presentes en el workspace:

9. El uso de los working sets

El workspace puede contener rápidamente varios proyectos, incluso decenas de proyectos. Los ‘working sets’ van a permitir ordenar el workspace mediante la creación de grupos que reúnen los proyectos. Un proyecto puede pertenecer a varios «working sets» al mismo tiempo.

La visualización en modo « working set » se realiza en el menú de la vista Package Explorer:

El mismo menú también contiene comandos para llenar los working set con los proyectos.

10. Exportar el workspace para compartirlo

Por último, una vez que el workspace está ordenado, con los «working sets», es posible exportar el contenido de un archivo ‘Team Project Set’. Este archivo contiene todas las URL de acceso a tu gestionario de configuración (cvs, svn, …), y también todos los «working set» definido.

Sólo se necesita que una persona defina un workspace de referencia que contenga todos los proyectos, ordenados por working sets, y exporte el workspace en un archivo almacenado en un disco compartido:
  Un nuevo desarrollador puede instalar una nueva estación en 3 pasos:

  • instalar Eclipse con sus herramientas
  • importar las preferencias comunes
  • importar el fichero team project set del proyecto

 

Commentaires Utilisateurs


  1. jennifer
    3 marzo 2014

    Muy buen tutorial, me sirvio mucho!

Deja una respuesta