¿Cómo puedo especificar una entrada Eclipse .classpath para una plataforma O/S específica?

Question

Estoy trabajando en un proyecto de SWT como parte de un equipo. Estamos constantemente rompiendo el entorno de compilación de los demás porque el archivo .classpath de Eclipses está registrado en el control de versiones e incluimos diferentes bibliotecas SWT para nuestras máquinas.

Dependiendo de quién cometió el pasado, la entrada .classpath puede ser:

<classpathentry kind="lib" path="lib/swt/swt-win32.jar"/> 

o

<classpathentry kind="lib" path="lib/swt/swt-carbon.jar"/> 

o

<classpathentry kind="lib" path="lib/swt/swt-gtk.jar"/> 

Parece ser que las bibliotecas son mutuamente excluyentes, es decir, no puede incluirlos todos a la vez y dejar que SWT lo resuelva. Así que tenemos que filtrarlos para cada plataforma de alguna manera ...

¿Alguien tiene alguna idea sobre cómo hacer esto? Mi idea inicial era dividir esto en su propio archivo ".classpath-swt" (ignorado por el VCS), autogenerarlo usando Ant e incluirlo en el .classpath principal, pero parece que Eclipse no es compatible con la división de la archivo .classpath.

Nuestra solución actual es evitar cometer el .classpath a menos que realmente hayamos cambiado las dependencias, sin embargo, esto todavía significa que un número de personas tiene que arreglar sus entornos de desarrollo cada vez que se cambia .classpath.

Cualquier sugerencia será muy apreciada, siempre y cuando no lo es "no utilizar Eclipse" ya que esto no es una opción para este proyecto :)

Answer 1

Eclipse le permitirá definir las variables de ruta de clases para que pueda mantener la .classpath es lo mismo, pero cada desarrollador debe configurar su Eclipse según la plataforma. Al menos podrías versionar el archivo .classpath. Tendrá que modificar la estructura de directorios donde almacena sus jarras SWT a algo donde el nombre del jar no cambia por plataforma. Este menú se puede encontrar en: "Ventana-> Preferencias> Java> Vía de construcción"

SWTJARDIRECTORY/ 
    WIN32/ 
     SWT.JAR 
    CARBON/ 
     SWT.JAR 
    GTK/ 
     SWT.JAR 

Ex.

SWT_PLATFORM="SWTJARDIRECTORY/GTK", set by developer in Eclipse 

.classpath

SWT_PLATFORM/SWT.JAR 

Answer 2

¿Qué tal, simplemente configurando sus propias instancias y para ello un componente de su entorno no mantenerlo en su control de código fuente?

Alternativamente, podría almacenar un archivo classpath para cada entorno, quizás en otro directorio y en un archivo ant, es decir, build-setup-env.xml, simplemente podría tener un objetivo para cada entorno que copie el correcto. En cuanto a mantener una copia de esto en control de fuente, debería asegurarse de copiarlo cuando se actualice.

Answer 3

Debe tener estas bibliotecas en un proyecto separado y fácilmente identificable en lugar de colocarlas en todos y cada uno de los proyectos.

E.g. crea un proyecto llamado "00-swt-provider" (por lo que va arriba) y deja que haga referencia a uno de "00-swt-provider-carbon", "00-swt-provider-win32" o "00-swt-provider" -gtk ".

Cualquiera de estos exportan las bibliotecas nativas apropiadas para la plataforma determinada y el único enlace está en 00-swt-provider. El proyecto real solo hace referencia a este meta proyecto.

Usamos una variante de esto internamente - nos funciona bien.

Answer 4

SWT lo hace por no versionando el archivo .classpath, pero por versiones múltiples archivos .classpath_ * separados con el sistema operativo y el sistema de ventanas adjuntos, p. .classpath_win32_win32. Por lo tanto, cuando revisa las fuentes del repositorio, se espera que copie el archivo classpath apropiado en .classpath y vuelva a compilar su proyecto.