Debería confirmar los archivos modificados por eclipse

Question

Heredé un proyecto de Java en la forma de un proyecto de eclipse. Después de cambiar la configuración de Tomcat (de v6 a v7), Subclipse me impulsó a cometer los siguientes archivos

• .classpath
• org.eclipse.core.prefs
• org.eclipse.common.project.facet .core.refs
• org.eclipse.common.project.facet.core.xml

Will cometer ellos ayudar a los miembros de mi equipo o va a meterse con su espacio de trabajo?

¿Cuál es el enfoque de mejores prácticas para esto?

Answer 1

En general, debe registrarse (y comprometerse después de los cambios) todo lo que sí contribuye a la construcción Y no se puede volver a generar mediante la reconstrucción completa Y es específico de la estación de trabajo. (Las implicaciones de esta declaración dependen de su proceso/proceso de compilación, que es la intención).

Esto implica que debe excluir todo lo que se vuelve a generar después de compilación completa, etc. por lo que no se registra (y no se ofrece para registrarse).

Answer 2

Lo que hemos hecho es ignorar estos archivos, ya que pueden arruinar el espacio de trabajo de otros en el proyecto.

Ignorarlos también hace que su proyecto sea más limpio, lo cual siempre me gusta.

Answer 3

Estos archivos pueden contener rutas de acceso específicas del entorno, por lo que sugeriría no registrarlas. En mi proyecto actual, utilizamos scripts ant para crear el proyecto y realizar la comprobación inicial de todo nuestro código.

Answer 4

Es mejor no comprometer esos archivos ya que las rutas/configuraciones pueden diferir en las diferentes estaciones de trabajo.

Es posible que desee utilizar alguna herramienta de compilación para solucionar esto. (por ejemplo, Maven)

Como si alguno de los miembros del equipo no estuviera usando eclipse (usando algún otro ide), esos archivos no tienen ningún significado para ellos.

Si todo el mundo comete configuraciones IDE diferentes, imagine qué clase de desorden puede causar.

EDITAR:

Más explicaciones;

He trabajado en equipos que las personas utilizan NetBeans, Eclipse, IDEA ... durante mucho tiempo y no es realmente una opción para ellos cambiar el IDE. Solo afectará la productividad de esa persona.

Cuando las personas se acostumbran a sus IDEs aprenden shorcuts, saben dónde buscar algunas funciones (refactorizar/generar getter setter/implementar anula los métodos necesarios ...) así que si los fuerza a utilizar algún otro IDE solo hará las cosas más difíciles para ellos y más lentos para el proceso general. En mi humilde opinión y de mi experiencia con una base de código flexible siempre es bueno. Soy un tipo eclipsado y probablemente no querría trabajar con ningún otro IDE, ya que conozco muchos shorcuts que hacen las cosas más rápidas/fáciles para mí y esos shorcuts son diferentes en IDE diferentes.

Todos los archivos IDE pueden ser regenerados automáticamente por el propio IDE, probablemente con solo un par de clics.

Y mi proyecto actual tiene 3 desarrolladores, cada uno usando diferentes IDE eclipse (me), NetBeans, IDEA sin ningún problema. No quiero ver los archivos de configuración de IDEA o NetBeans que no tienen sentido para el eclipse cuando reviso el origen del repositorio. Del mismo modo para ellos también.

Answer 5

Sí, pero asegúrese de que las rutas sean relativas en el espacio de trabajo en lugar de rutas absolutas. Tener estos archivos en el espacio de trabajo permite a los miembros de su equipo trabajar en el mismo entorno que usted. También hace que configurar un nuevo entorno de desarrollo sea mucho más fácil: simplemente lo verifica fuera del control de fuente y en Eclipse use 'Importar ...> Proyectos existentes en el área de trabajo'

Como mencionó @adamdunne, estos archivos pueden contener entornos específicos caminos. Sin embargo, si tiene cuidado de asegurarse de que las rutas sean relativas dentro de su área de trabajo, mediante el uso de variables y al no importar archivos jar externos, es decir, al incluir únicamente archivos jar de proyectos en el área de trabajo, entonces debería estar bien. En mi espacio de trabajo revisamos esos archivos y hemos tenido muchos menos problemas para configurar el desarrollo. entornos desde.

Answer 6

Trabajo en un proyecto donde confirmamos el archivo .classpath ya que es muy útil que todos los desarrolladores utilicen el mismo :) Si solo usa dependencias dentro de su área de trabajo, este archivo usa rutas relativas y por lo tanto debería ser igual en todos máquinas. Aunque este archivo no sea necesario para compilar (con hormiga, por ejemplo), es muy conveniente sincronizarlo.

En contraste los org.eclipse.core.prefs tiendas (que yo sepa) proyecto específico, pero personales preferencias de los desarrolladores, que no me registrarnos.

Con las facetas Google No trabajo todavía en un proyecto real, entonces no puedo decirlo. Pero, en general, creo que depende de la información en el archivo y de la forma en que trabaja.

Si no está seguro, inténtelo. Si obtienes conflictos en estos archivos todo el día, esto es una pista que puede que no estés en la forma perfecta.

Answer 7

Estos archivos pueden ser muy útiles para compartir configuraciones entre desarrolladores. La alternativa es usar Maven (que es una gran tarea para un proyecto establecido) o tener instrucciones paso a paso constantemente desactualizadas y nuevos desarrolladores que tardan medio día hasta que puedan construir el proyecto.

Sin embargo, debe asegurarse de que estas configuraciones sean portátiles, es decir, que no contengan rutas de acceso locales. Esto se puede hacer mediante el uso de rutas relativas dentro del espacio de trabajo, variables de ruta de eclipse y bibliotecas de usuario.

Answer 8

Como regla general, debe evitar la asignación de archivos que contengan preferencias del usuario y detalles del proyecto que ese Eclipse y/o sus complementos puedan regenerarse.

Pero en algunos casos las cosas son un poco turbias. Por ejemplo, el archivo .classpath puede ser ser la fuente principal de la ruta de compilación de Eclipse; p.ej. si tiene archivos JAR en el árbol de proyectos en lugar de utilizar Maven. (Con Maven, el complemento m2eclipse genera el archivo .classpath a partir de la información de dependencia en el archivo POM y, por lo tanto, el archivo no debe registrarse).

Además, algunas de las facetas están en el límite. Por ejemplo, en proyectos con JSPs y Javascripts, he encontrado que es esencial cambiar las propiedades de las facetas para desactivar los validators rotos. Y hay un buen caso para tratar esos cambios como parte del proyecto y no como preferencias personales.

La separación de las preferencias de grupo/proyecto de las preferencias personales es un área donde (IMO) Eclipse es seriamente deficiente.