para - ¿Es una buena práctica incluir archivos de proyectos de Eclipse con fuentes en SCM?
maven integration for eclipse (4)
Casi todos los proyectos (de trabajo) que he encontrado almacenan los archivos .project en un SCM. Principalmente por el motivo de que los constructores, etc. están almacenados en el archivo. Entonces todos los desarrolladores tienen una configuración consistente en Eclipse.
Imagine el escenario en el que todos están usando Checkstyle, aparte de un desarrollador, que insiste en poner pestañas en sus archivos :-).
No solo se aplica a .project, sino a .classpath, .checkstyle, todo en .settings.
Lo único que debe tener cuidado es que todo lo que se refiere en sus proyectos tiene una ruta relativa al proyecto, por ejemplo, la configuración de su estilo de control. Esto significa que todo lo que use probablemente también estará en el SCM. Pero esto es una ventaja, porque todo esto es parte de su proceso ¿verdad?
Lo anterior no se aplica necesariamente a los proyectos de FOSS, debido a la diversidad de IDEs utilizados.
Tenemos un proyecto Maven de varios módulos bastante complicado. Hay módulos Flex, módulos GWT, módulos Java y una serie de módulos WAR. Para simplificar el proceso de importación de estos proyectos en Eclipse, históricamente hemos incluido todos los archivos de proyectos de Eclipse relevantes en el árbol de fuentes.
Sin embargo, esto ha sido una fuente de problemas en el pasado porque a veces esos archivos se modifican accidentalmente y se registran ... causando problemas para otros desarrolladores. Con el advenimiento de M2E y su nuevo soporte para los configuradores para ayudar a configurar los proyectos de Eclipse en la importación, estamos reconsiderando esta estrategia.
En general, ¿los proyectos incluyen estos archivos Eclipse en Subversion / Git / etc.?
Personalmente, no recomiendo incluir los archivos de configuración de proyecto en su SCM. El archivo .project contiene la ruta relativa o absoluta, o URI, que puede ser muy de usuario a usuario. Las especificaciones para el archivo .project se pueden encontrar aquí .
Respuesta de nivel superior: eso es totalmente una cuestión de gusto :-)
Personalmente, para proyectos "internos" (usted tiene cierto control sobre los entornos de otros desarrolladores), incluyo los archivos Eclipse, con la advertencia de que todos deben usar rutas relativas en sus configuraciones. (Cada pocos meses teníamos un salto de compilación porque la ruta de la biblioteca estaba codificada. Le tomó unos segundos arreglarla, pero era molesto.) También usualmente he usado mucho cosas como el formato de código de Eclipse y las advertencias del compilador. configuración para facilitar la vida (por ejemplo, no hay grandes registros de Subversion porque los editores de alguien se pelearon por las pestañas de formateo).
Como beneficio adicional, cuando traiga un nuevo desarrollador, el sistema de Eclipse Subversion check-out configurará automáticamente el proyecto cuando detecte los archivos del proyecto en su troncal / sucursal. Esta es una Ganancia doble si usa Eclipse para administrar su compilación (en lugar de, por ejemplo, Ant o Make).
Si estás en un equipo más diverso (p. Ej .: no homogéneamente (sic?) Usando Eclipse), no son "mucho" molestos, en la práctica. Tengo un proyecto "colaborativo" en el que trabajo que tiene una carpeta llena de archivos de control de MicroSoft Visual Studio y un archivo .project, y tienen que mantenerse sincronizados ad-hoc, pero al menos hay "solo dos" conjuntos de esos archivos para sincronizar. Sin ellos en Subversion, habría uno por desarrollador ...
También he escuchado sobre el uso de un "proyecto ficticio" para guardar los archivos del proyecto. p.ej
svn://someplace.nn/projects/MyProject/trunk —> source
svn://someplace.nn/projects/MyProject.control/trunk —> project control files
El único lugar que he visto fue en un proyecto con una gran sucursal de GPL y un pequeño repositorio de plug-ins locales no pertenecientes a GPL ... la sucursal de GPL no tenía archivos .project, como la mayoría de los ''Net colaboradores no estaban usando Eclipse, los archivos del proyecto estaban en el servidor Subversion interno (privado) y un tercer proyecto contenía el código de plug-in de propiedad. (Y un cuarto para el arte, un quinto para la música ...)
puedes considerar agregar el plugin maven-eclipse a tu pom. por lo tanto, el desarrollador podría verificar los códigos fuente y construir localmente su proyecto Eclipse e importarlo al área de trabajo.
también si tiene archivos de configuración relacionados con eclipse común (o plugin de eclipse), también puede definirlos en maven-eclipse-plugin. por ejemplo, checkstyle.xml, codeTemplate.xml, codeFormatter.xml .... guardar aquellos archivos en scm podría ser una buena idea.