2010-06-04 17 views
5

Tengo una aplicación que se compone de aproximadamente 10 proyectos diferentes de Eclipse. Algunos proyectos deben compilarse con Java 5 y otros con Java 6. Tengo ambos JDK registrados en la lista "JRE instalados" de Eclipse como "jdk5" y "jdk6", respectivamente.Eclipse: ¿Hay una manera fácil de coordinar "JRE instalados" en un equipo?

El JRE apropiado está en la ruta de clase de construcción de cada proyecto, que se refleja en los archivos .classpath. Sin embargo, otros miembros de mi equipo están usando diferentes nombres simbólicos para estos JRE en sus máquinas. Además, los archivos .classpath se controlan en el control de origen. Como resultado, las personas necesitan realizar cambios locales en su archivo .classpath para poder compilar.

Mi instinto es elegir una convención de nomenclatura para la lista JRE instalada y pedir a todos los miembros del equipo que la sigan. Sin embargo, esto solo complica el proceso de configuración de un nuevo desarrollador. Realmente, solo quiero decir "crea este proyecto con Java 5" y "crea ese proyecto con Java 6". No me importa dónde están instalados, ni cuál es su nombre simbólico. ¿Eclipse es compatible con este tipo de configuración?

Respuesta

3

Entornos de ejecución son los que desea (Preferencias -> Java -> JRE instalados -> Entornos de ejecución). Puede cambiar el classpath de sus proyectos para usar una biblioteca de sistema JRE que corresponda a una versión particular de Java, como "J2SE-1.5" o "JavaSE-1.6". Luego, Eclipse categorizará los JRE instalados en esas categorías y usará el apropiado al construir sus proyectos.

0

Puede configurar los ajustes del compilador específicos del proyecto en Preferencias-> Java-> Compiler. Sin embargo, esto solo le permite establecer el nivel de cumplimiento, no elegir un JDK en particular. Pero tal vez eso ya es suficiente para su propósito?

2

Honestamente, utilizo el maven (maven-compiler-plugin y perfiles) para exactamente esto.

<plugin> 
<artifactId>maven-compiler-plugin</artifactId> 
<configuration> 
    <source>1.5</source> 
    <target>1.5</target> 
</configuration> 
</plugin> 

El uso de un sistema como el experto (o una hormiga, etc) nos ayuda enormemente con problemas de ruta de clases/Medio Ambiente/os-disparidades entre los desarrolladores.

+0

Iba a mencionar que no estamos usando maven y no estamos actualmente en un estado para poder cambiar a él. No tengo experiencia personal con eso, pero la mayoría del equipo quiere cambiar. Tenemos mucha simplificación de compilación para hacer primero. –

+0

Gotcha. En ese caso (como otros mencionaron) un esquema de nomenclatura estandarizado es probablemente su mejor opción. Tal vez incluso una ubicación local estándar si es posible usando las variables env como elduff menciona. O incluso una unidad compartida ... – Quotidian

0

Si está sincronizando sus archivos de proyecto, eclipse mantiene un JDK actual en la pestaña Bibliotecas de la configuración de la ruta de compilación de proyectos. Esto funcionará bastante bien siempre que todos tengan el mismo JDK instalado y cargado en eclipse.

Siempre que sea posible, seguiría recomendando la solución maven que Quotidian sugirió, pero he tenido bastante éxito manualmente siempre y cuando cada estación de trabajo de desarrollador esté configurada de la misma manera. Sin embargo, esto puede colgarte si tienes desarrolladores que ejecutan diferentes sistemas operativos, ya que podría buscar "C: \ Program Files \ java" en un sistema Linux, o "/ user/lib/jvm /" en wndows, ninguno de los cuales existiría

0

Si tiene que comprobar que el .classpath fies está en el control de código fuente, le recomiendo que siga su idea de que todos los desarrolladores instalen sus JDK en la misma ubicación (o utilice un entorno común). nombre de la variable que apunta a las ubicaciones). Creo que es mucho más fácil para los desarrolladores en el mismo equipo tener configuraciones de entorno muy similares, y si esa configuración de env común está bien documentada. De esta forma, a medida que los nuevos desarrolladores se sumen, puede enviarlos a su documentación para la configuración de env y tenerlos en funcionamiento rápidamente; no debería haber necesidad de perder tiempo al resolver los problemas relacionados con la ubicación de sus JDK.

Sin embargo, si no es una opción y ya está usando Maven, entonces podría considerar eliminar los archivos .classpath del control de código fuente. Recientemente lo hemos hecho y todos los desarrolladores ejecutan el plugin Maven eclipse para generar (o actualizar) sus propios archivos .classpath basados ​​en lo que está en el archivo pom.xml. (es decir, mvn eclipse: eclipse para ejecutar ese complemento).

Cuestiones relacionadas