oxygen - gitflow eclipse
¿Es.settings/org.eclipse.jdt.core.prefs parte del proyecto? (4)
¿El archivo .settings/org.eclipse.jdt.core.prefs parte del proyecto o es parte de mi configuración de eclipse personal?
¿Debo agregarlo al control de versiones?
Aquí está el problema de ponerlo bajo el control de versión ... Si importa y abre un proyecto, Eclipse insiste cuando se llama a IProject.open (...) al tocar el archivo en la carpeta .settings ... y esto es antes de poder registrar el proveedor del equipo en el objeto IProject. Eso significa que validateEdit no se activará y obtendrá errores molestos si hace clic en "sí" o "no" en la ventana emergente y pregunta "¿desea que se pueda escribir?" Eso está muy bien para los proveedores optimistas de bloqueo de archivos, pero no tanto para los "pesimistas". Para nosotros esto es solo otra molestia de eclipse.
Si depende de mí, no hay manera de poner esto en control de la fuente.
Contrariamente a la opinión de @ nitind, no. No debe poner ninguna configuración específica de IDE bajo el control de versión. Excepto que estás desarrollando funciones o complementos IDE.
En caso de que realmente tenga una configuración IDE obligatoria para todo el equipo, sería una buena idea ponerlas bajo el control de la versión, pero la OMI con una configuración obligatoria para todo el equipo no es una buena idea en sí misma.
Para todos los demás casos, la configuración de IDE compartida es mala para las construcciones portátiles, incluso con el mismo IDE, y en el mejor de los casos es inútil para los usuarios de otros IDE.
EDITAR: Debo diferenciar, dependiendo del grupo objetivo de su proyecto. Si está desarrollando un producto de código cerrado en un equipo que trabaja con eclipse, entonces mantener estas preferencias bajo el control de versiones es útil y una buena idea. Si está desarrollando una biblioteca, una fuente cerrada o abierta, o un proyecto de fuente abierta, considero que ignorar las preferencias es más apropiado y cortés.
EDIT2: Me temo que @Bananenweizen está entendiendo mal lo que estoy tratando de decir.
Sé que estas configuraciones son las configuraciones del compilador de eclipse. Siguen siendo IDE específicos en el sentido de que no tendrán ningún efecto en Netbeans o IntelliJ, ya que no tendrán ningún impacto en las construcciones de hormigas o expertos desde la línea de comandos.
Sí, dejar estos ajustes fuera del control de versión puede traerle muchas líneas onduladas rojas en eclipse en una máquina diferente. No lo hará, si se trata de un proyecto de Maven con un nivel de fuente establecido, por cierto, no estoy seguro acerca de ant.
Eclipse no está construyendo los proyectos por sí mismo, los construye con hormiga si es un eclispe o un proyecto de hormiga, o con maven si es un proyecto de maven. Tanto ant como maven tienen configuraciones específicas para la versión de origen que no dependen de los IDE.
Y aquí es donde deberían estar estas configuraciones, en el archivo de compilación. Y el archivo de compilación debe estar bajo control de código fuente. Las excepciones que mencioné anteriormente todavía se aplican.
La respuesta es "sí" y aquí encontrará la motivación para hacerlo y la forma correcta de hacerlo: vea la charla "Cómo cometer los metarchivos IDE: conceptos erróneos, malentendidos y soluciones". o mire las slides correspondientes de EclipseCon Europe 2015 de Aurélien Pupier @apupier (Ingeniero de Software Senior, especialista en Eclipse).
Si deberías. Si este archivo no está bajo el control de versiones, entonces no puede crear compilaciones reproducibles del mismo proyecto, porque ya no es autónomo, sino que depende de su instalación específica de Eclipse y sus configuraciones.
Si importa este proyecto a otro espacio de trabajo (en su o en cualquier otra máquina), puede comportarse de manera completamente diferente, ya que la configuración de cumplimiento del compilador, la configuración de las advertencias del compilador y muchas otras cosas faltan repentinamente o son diferentes. Es probable que un proyecto de este tipo muestre de repente advertencias / errores en el nuevo espacio de trabajo, mientras que antes estaba completamente bien.
Nota: Todo esto también requiere que realmente configure todas las configuraciones relacionadas con Java en las propiedades del Proyecto. Nunca use la configuración del compilador de Java en Ventana -> Preferencias si desea tener proyectos independientes.
Solo para dar un ejemplo concreto: si ha configurado el nivel de cumplimiento del compilador de sus proyectos en Java 6, ya que está usando características específicas de Java 6 (como Anotar anotaciones en interfaces), entonces el proyecto creará muchos errores de compilación en las máquinas de otras personas. . Esto se debe a que el nivel de cumplimiento del compilador predeterminado en cada área de trabajo de Eclipse es Java 1.5, y en Java 1.5 esa anotación de anulación simplemente no está permitida.
Esto no tiene nada que ver con si está desarrollando fuente cerrada o fuente abierta, como se indica en la otra respuesta.