java - tres - ¿Debo mantener mis archivos de proyecto bajo control de versión?

software para control de versiones de archivos (12)

¿Debo mantener los archivos del proyecto como el .project, .classpath, .settings de Eclipse, bajo el control de la versión (por ejemplo, Subversion, GitHub, CVS, Mercurial, etc.)?

.project y .classpath archivos sí. Sin embargo, no mantenemos nuestra configuración IDE en control de versiones. Hay algunos complementos que no hacen un buen trabajo de configuración persistente y encontramos que algunas configuraciones no eran muy portátiles de una máquina de desarrollo a la siguiente. Entonces, tenemos una página Wiki que destaca los pasos necesarios para que un desarrollador configure su IDE.

Aunque generalmente estoy de acuerdo con el enfoque de "no generar archivos de versión", tenemos problemas con él y tenemos que volver atrás.

Nota: También estoy interesado en la respuesta de VonC , particularmente sobre el punto de "obtener Eclipse en cuestión de minutos". Pero no es decisivo para nosotros.

Nuestro contexto es Eclipse + Maven, usando el plug-in m2eclipse. Tenemos un entorno de desarrollo común, con directorios comunes tanto como sea posible. Pero a veces sucede que alguien probaría un complemento, o cambiaría pequeñas cosas en la configuración, o importaría un segundo espacio de trabajo para una rama diferente ...

Nuestro problema es que la generación de .project se realiza al importar un proyecto en Eclipse, pero no se actualiza en todos los casos más adelante . Es triste, y probablemente no permanente, ya que el plug-in m2eclipse mejorará, pero es cierto ahora mismo. Así que terminamos teniendo diferentes configuraciones. Lo que tuvimos hoy fue eso: varias naturalezas se agregaron a muchos proyectos en alguna máquina, que luego se comportaron de manera muy diferente :-(

La única solución que vemos es la versión del archivo .project (para evitar riesgos, haremos lo mismo para .classpath y .settings). De esa forma, cuando un desarrollador cambia su pom, los archivos locales se actualizan usando m2eclipse, todos se comprometen entre sí, y otros desarrolladores verán todos los cambios.

Nota: en nuestro caso, usamos nombres de archivo relativos, por lo que no tenemos problemas para compartir esos archivos.

Por lo tanto, para responder a su pregunta, digo que sí, confirme esos archivos.

También me gustó:

answer Rich Seller

Desea mantener en control de versiones cualquier archivo de configuración portátil ,
sentido:
Cualquier archivo que no tenga una ruta absoluta en él.
Eso incluye:

.proyecto,
.classpath ( si no se utiliza ninguna ruta absoluta , que es posible con el uso de variables IDE o variables de entorno de usuario)
Configuración IDE (que es donde no estoy de acuerdo con la respuesta ''aceptada''). Esas configuraciones a menudo incluyen reglas de análisis de código estático que son de vital importancia para aplicar de forma coherente para cualquier usuario que cargue este proyecto en su espacio de trabajo.
Las recomendaciones de configuraciones específicas de IDE deben escribirse en un gran archivo README (y también versiones, por supuesto).

Regla de oro para mí:
Debe poder cargar un proyecto en un área de trabajo y tener todo lo que necesita para configurarlo correctamente en su IDE y comenzar en minutos.
Sin documentación adicional, páginas wiki para leer o no.
Cargalo, configúralo, ve.

Esta es toda la opinión, supongo, pero las mejores prácticas a lo largo de los años indican que los archivos específicos de un IDE determinado no deberían almacenarse en control de fuente, a menos que toda su organización esté estandarizada en un IDE y nunca tenga la intención de cambiar.

De cualquier forma, definitivamente no quiere que se guarden las configuraciones del usuario, y .project puede contener configuraciones que son realmente específicas del desarrollador.

Recomiendo usar algo como Maven o Ant como un sistema de compilación estandarizado. Cualquier desarrollador puede obtener una classpath configurada en su IDE en unos segundos.

Esto es lo que considero que son archivos generados, y como tal, nunca los coloco bajo control de versiones. Pueden ser diferentes de una máquina a otra y de un desarrollador a otro, por ejemplo, cuando las personas tienen instalados diferentes plugins de Eclipse.

En su lugar, utilizo una herramienta de compilación (Maven) que puede generar versiones iniciales de estos archivos cuando realiza un nuevo pago.

Estoy dividido entre dos opciones aquí.

Por un lado, creo que todos deberían tener la libertad de usar el conjunto de herramientas de desarrollo con el que son más productivos, siempre que todos los artefactos fuente estén almacenados en control de versión, y el script de construcción (digamos ANT o Maven) garantice el cumplimiento de los estándares especificando exactamente qué JDK usar, de qué versiones dependen las bibliotecas de terceros, ejecutando verificaciones de estilo (p. ej., estilo de comprobación) y ejecutando pruebas unitarias, etc.

Por otro lado, creo que muchas personas usan las mismas herramientas (por ejemplo, Eclipse) y, a menudo, es mucho mejor tener algunas cosas estandarizadas en tiempo de diseño en lugar de tiempo de compilación, por ejemplo, Checkstyle es mucho más útil como complemento de Eclipse que como una tarea ANT o Maven: es mejor estandarizar el conjunto de herramientas de desarrollo y un conjunto común de complementos.

Trabajé en un proyecto donde todos usaban exactamente el mismo JDK, la misma versión de Maven, la misma versión de Eclipse, el mismo conjunto de complementos de Eclipse y los mismos archivos de configuración (por ejemplo, perfiles de Checkstyle, reglas de formateador de código, etc.). Todos estos se mantuvieron en control de fuente - .project, .classpath y todo en la carpeta .settings. Hizo la vida realmente fácil durante las fases iniciales del proyecto cuando las personas continuamente modificaban las dependencias o el proceso de compilación. También ayudó inmensamente cuando se agregaron nuevos iniciadores al proyecto.

En resumen, creo que si no hay demasiadas posibilidades de una guerra religiosa, debe estandarizar el conjunto básico de herramientas de desarrollo y complementos y garantizar el cumplimiento de la versión en sus scripts de compilación (por ejemplo, especificando explícitamente la versión de Java). no creo que haya mucho beneficio para almacenar el JDK y la instalación de Eclipse en el control de la fuente. Todo lo demás que no sea un artefacto derivado, incluidos los archivos de tu proyecto, la configuración y las preferencias de los complementos (en particular, el formateador de códigos y las reglas de estilo), debe pasar al control de código fuente.

PD: si usa Maven, existe un argumento para decir que los archivos .project y .classpath son artefactos derivados. Esto solo es cierto si los genera cada vez que hace una compilación, y si nunca los ha tenido que modificar a mano (o los ha cambiado inadvertidamente cambiando algunas preferencias) después de generarlos desde el POM

No, porque solo controlo los archivos de versión que se necesitan para construir el software. Además, los desarrolladores individuales pueden tener su propia configuración específica del proyecto.

No, soy un usuario pesado de Maven y uso el plugin Q for Eclipse que crea y mantiene actualizados .project y .classpath. Para otras cosas, como la configuración de los complementos, generalmente mantengo un README o Wiki-page sobre eso.

También aquellos con los que he trabajado que prefieren otros IDE simplemente usan los plugins de Maven para generar los archivos necesarios para mantener contentos a sus IDE (y a ellos mismos).

Parece que estos archivos de proyecto pueden cambiar con el tiempo a medida que trabajas en un proyecto, así que sí, los coloco bajo control de versiones.

Sí, a excepción de la carpeta .settings. Cometer los otros archivos funciona bien para nosotros. Hay una pregunta similar here .

Sí. Todo menos producción de compilación.

Usamos IntelliJ IDEA y mantenemos versiones ''.sample'' de los archivos de proyecto (.ipr) y de módulo (.iml) bajo control de versión.

Algo más grande aquí es compartir y reutilizar que versionar, en mi humilde opinión. Pero si va a compartir estas configuraciones, ¿qué mejor lugar para colocarlas que el repositorio, justo al lado de todo lo demás?

Algunas ventajas de los archivos de proyectos compartidos y versionados:

Puede consultar cualquier etiqueta / sucursal y comenzar a trabajar en ella rápidamente
Facilita a un nuevo desarrollador configurar primero el entorno de desarrollo y ponerse al día
Esto se adhiere mejor a DRY, que siempre es muy satisfactorio. Antes de esto, todos los desarrolladores tenían que configurar estas cosas de vez en cuando, esencialmente haciendo un trabajo repetido. Por supuesto, todos tenían sus propias pequeñas maneras de evitar repetirse, pero mirando al equipo como un todo, había un montón de esfuerzos duplicados.

Tenga en cuenta que en IDEA estos archivos contienen configuraciones tales como: cuáles son los directorios "fuente" y "fuente de prueba"; todo sobre las dependencias externas (dónde se encuentran los archivos jar de la biblioteca, así como fuentes relacionadas o javadocs); opciones de compilación, etc. Esto es algo que no varía de desarrollador a desarrollador (estoy en desacuerdo con this bastante fuerte). IDEA almacena configuraciones de IDE más personales en otros lugares, así como también configuraciones de complementos. (No conozco bien a Eclipse, puede o no ser muy diferente).

Estoy de acuerdo con esta respuesta que dice:

Debe poder cargar un proyecto en un área de trabajo y tener todo lo que necesita para configurarlo correctamente en su IDE y comenzar en minutos. [...] Cargarlo, configurarlo, listo.

Y lo tenemos así, gracias a los archivos de proyectos versionados.