.classpath y .project - verificar en el control de la versión o no?

Question

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 configurarlo todo 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 llevaría a conflictos constantes en esos archivos? ¿Hay alguna manera alternativa de hacer que el proyecto sea fácil de configurar en eclipse?

Answer 1

Definitivamente sí, como dije en "Do you keep your project files under version control?"

"Carguelo, configúralo, ve".

... Pero esto es realmente cierto sólo para configuraciones Eclipse3.5 recientes, en los que construyen caminos apoyo rutas relativas:

---

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

(desde 3.6M5)

Answer 2

Definitivamente no - en general es una idea terrible para distribuir archivos de proyecto a través de la subversión. Especialmente porque alguien podría modificarlos de una 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 configurado una página de confluencia que describe cómo comenzar con el proyecto en cada IDE de populer: IntelliJ, Eclipse, NetBeans. Un archivo README en Subversion contiene la misma información.

Answer 3

Revisaría estos archivos para comenzar por los nuevos usuarios tan fácil como sea 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: trátelos con cuidado. No debe aplicar pathes absolutos en el código fuente, ni siquiera debe hacerlo en los archivos de configuración.

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

Answer 4

Yo recomendaría que compruebe los archivos en subversión SI no contienen rutas absolutas y otros datos que los relacionarían directamente con el entorno de un único desarrollador.

Si los archivos contienen rutas absolutas y similares, un LÉAME sería una mejor opción.

Answer 5

Sí, definitivamente verifíquelos, pero asegúrese de documentar cualquier dependencia de ruta y evitar rutas absolutas si es posible.

Si no los registra, cualquiera que verifique el proyecto tendrá que volver a crear todos esos ajustes, lo que es molesto y potencialmente propenso a errores.

Algunas configuraciones complejas pueden ser mejor manejadas por un script para generar estos archivos, pero por lo general es mejor simplemente comprobar en.

Answer 6

Yo voto que no, pero eso es porque yo generalmente generar estos archivos de experto

Answer 7

En mi experiencia, con exclusión de los pocos casos en que están involucrados los ajustes puramente locales, todo debe estar en control de código fuente. La ley del control de la fuente es que debe esperarse que todo lo que se empuja funcione para aquellos que se retiran. Por desgracia, eclipsar a menudo hace que este tipo de cosas para estar en .classpath:

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

Así que en mi Mac esto funciona, y tal vez alguien en un Mac tiene el mismo JRE, pero esto no va a funcionar para cualquier otra persona.

Además, no hay una manera fácil de evitar esto. Eclipse siempre agregará eso. QUIERO tener el archivo .classpath ahí, porque hay algunos JAR de terceros en nuestra carpeta lib donde nos importan las versiones, así que los dejamos ahí para que los nuevos desarrolladores no tengan que obtenerlos . Nos estamos moviendo a un sistema administrado, pero todavía hemos administrado las dependencias administradas + no administradas. Esto significa que todos los desarrolladores solo tienen que asegurarse de que haya dos directorios en sus .classpath s. Pero es mejor que tener que arreglar tu JRE cada vez que realizas una extracción y tener un cambio en tu .classpath cada vez que te comprometas.

Eclipse hace algunas otras cosas agradables para usted. El archivo .project generalmente será el mismo en todas las instancias, así que inclúyalo. Pero lo mejor del control de origen para eclipse es la configuración de configuraciones de ejecución. Debajo de la pestaña "Común" en el diálogo Ejecutar Configuraciones, guarde las configuraciones para que aparezcan para sus colegas bajo las listas de favoritos para Depurar y Ejecutar. Para mí, un montón de archivos .launch van en el directorio .settings, por lo que todos podemos usarlos.

Por eso digo: .settings directorio entra en control de código fuente para configuraciones de lanzamiento (excepto .prefs *)

.classpath se queda fuera

.project va en