.classpath y .project: ¿verificar el control de versiones o no?

Estoy ejecutando un proyecto java de código abierto que consta de varios módulos en un árbol de dependencias. Todos esos módulos son subdirectorios en un repositorio de subversión. Para los recién llegados a nuestro proyecto, es mucho trabajo configurar todo eso manualmente en eclipse.

No todos nuestros desarrolladores usan eclipse. Sin embargo, estamos considerando simplemente verificar los archivos .classpath y .project para ayudar a los recién llegados a comenzar. ¿Es esta una buena idea? ¿O eso conduciría a conflictos constantes en esos archivos? ¿Existe una forma alternativa de hacer que el proyecto sea fácil de configurar en eclipse?

Definitivamente sí, como dije en " ¿Mantienes los archivos de tu proyecto bajo control de versiones? "

"Cárgalo, configúralo, listo".

Pero ... esto es realmente cierto solo para la configuración reciente de Eclipse3.5, donde las rutas de compilación admiten rutas relativas :

Y Eclipse3.6 sería mejor, ya que admite rutas relativas para variables de ruta en Linked Resources:

(desde 3.6M5)

Definitivamente no, generalmente es una idea terrible distribuir archivos de proyecto a través de subversión. Especialmente porque alguien podría modificarlos de alguna manera extraña. Una buena página en la documentación del proyecto es una idea mucho mejor. Nuestro proyecto también tiene muchos módulos y una configuración compleja. Hemos creado una página de confluencia que describe cómo empezar con el proyecto en cada IDE popular: IntelliJ, Eclipse, NetBeans. Un archivo README en Subversion contiene la misma información.

Voto no, pero eso es porque generalmente generaría estos archivos desde maven

En mi experiencia, excluyendo los casos limitados en los que están involucradas configuraciones puramente locales, todo debería estar en control de fuente. La ley del control de la fuente es que se debe esperar que todo lo que se empuja hacia adentro funcione para quienes se retiran. Desafortunadamente, el eclipse a menudo hace que cosas como esta estén en .classpath:

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

Entonces, en mi Mac esto funciona, y tal vez alguien en una Mac tenga el mismo JRE, pero esto no funcionará para nadie más.

Además, no hay una forma fácil de evitar esto. Eclipse siempre agregará eso. QUIERO tener el archivo .classpath allí, porque hay algunos JAR de terceros en nuestra carpeta lib donde nos preocupamos por el control de versiones, así que los dejamos allí para que los nuevos desarrolladores no tengan que obtenerlos . Nos estamos moviendo a un sistema administrado, pero aún tenemos las dependencias administradas + no administradas registradas. Esto significa que todos los desarrolladores solo tienen que asegurarse de que haya dos directorios en sus .classpaths. Pero es mejor que tener que arreglar su JRE cada vez que extrae y tener un cambio en su .classpath cada vez que se compromete.

Sin embargo, Eclipse hace algunas otras cosas buenas por ti. El archivo .project generalmente será el mismo en todas las instancias, así que inclúyalo. Pero lo mejor del control de fuente para eclipse es la configuración de Ejecutar configuraciones. En la pestaña "Común" del cuadro de diálogo Ejecutar configuraciones, guarde las configuraciones para que aparezcan para sus colegas en las listas de favoritos para Depurar y ejecutar. Para mí, un montón de .launcharchivos van en el .settingsdirectorio, así que todos podemos usarlos.

Entonces digo: el .settingsdirectorio entra en el control de fuente para las configuraciones de inicio (excepto * .prefs)

.classpath se queda fuera

.project entra.

Verificaría estos archivos para que el inicio de los nuevos usuarios sea lo más fácil posible. En el mejor de los casos, el usuario debería verificar el proyecto y debería poder ejecutarlo sin conocimientos adicionales. Para estos archivos, las reglas son las mismas que para otros archivos del proyecto: manipúlelos con cuidado. No debe colocar parches absolutos en el código fuente, ni tampoco en los archivos de configuración.

Si los archivos se registran de manera que el proyecto se ejecute desde cero, no debería haber muchas fuerzas para cambiarlos.

Le recomendaría que verifique los archivos en subversión SI no contienen rutas absolutas y otros datos que los vincularían directamente al entorno de un solo desarrollador.

Si los archivos contienen rutas absolutas y similares, un archivo README sería una mejor opción.

Sí, definitivamente regístrelos, pero asegúrese de documentar las dependencias de las rutas y evitar las rutas absolutas si es posible.

Si no los registra, entonces cualquiera que revise el proyecto deberá volver a crear todas esas configuraciones, lo cual es molesto y potencialmente propenso a errores.

Algunas configuraciones complejas pueden manejarse mejor con un script para generar estos archivos, pero por lo general es mejor simplemente registrarlos.