que - Soporte Multi-IDE en Java para un equipo
netbeans 9 (9)
Admitimos intencionalmente múltiples IDEs del mismo repositorio SVN. Nuestro pensamiento era que queríamos asegurarnos de que, si una persona nueva se unía al equipo o alguien tenía que empezar a trabajar en una máquina nueva, queríamos que pudieran consultar la base de código, importarla al IDE e inmediatamente tener un trabajo. configuración capaz
Lo que eso significa para el desarrollador final es que no deben comprometer sus cambios a los archivos IDE. Todo lo demás (p. Ej., Src, test, lib, etc.) se convierte en el conjunto que normalmente actualizamos y comprometemos todos los días.
El beneficio adicional es que hemos eliminado por completo las guerras de IDE aquí: las personas de Netbeans y Eclipse viven en perfecta armonía (mirando con recelo a la gente de IntelliJ, pero bueno ... ;-).
¿Cuál es la mejor manera de permitir que un equipo de programadores use Netbeans, Eclipse e IntelliJ en el mismo proyecto, eliminando así la pregunta "¿qué IDE es mejor?".
¿Qué archivos deberían o no ser controlados en el control del código fuente?
Creo que la mejor manera es hacer que el proceso de compilación sea independiente de IDE. Esto significa que su proyecto no debe basarse en ningún archivo IDE específico para compilar, sino que debe usar un sistema de compilación externo, como Apache Maven , Apache Ant o incluso crear scripts personalizados. Maven es compatible con los IDE Java más populares, ya sea directamente o mediante complementos.
Si no desea utilizar un sistema de compilación externo, al menos debe hacer que el proyecto sea tan fácil de configurar como sea posible (es decir, teniendo carpetas estándar para bibliotecas compartidas y otras dependencias). Cuando he trabajado en equipos con múltiples IDEs en el pasado, pasé la mayor parte del tiempo resolviendo dependencias ya que los requisitos previos para construir el proyecto cambiaron con el tiempo. En el peor de los casos, incluso puede terminar con desarrolladores que no se molestan en obtener la última versión del repositorio de control de versiones, ya que piensan que la configuración del nuevo proyecto es una molestia.
Si su proyecto tiene muchas dependencias de biblioteca, creo que es una buena idea ponerlas a disposición en forma binaria en el repositorio de control de versiones. De esta forma, las personas no tienen que resolver todas las dependencias de las dependencias, etc. solo para construir un solo proyecto. Sin embargo, esto requiere que tengas a alguien responsable de mantener los binarios "oficiales" actualizados siempre que cambien. (Esta es más o menos la misma filosofía utilizada por el repositorio de Maven, pero los principios pueden aplicarse manualmente incluso cuando no se usa Maven).
Hay muchas consideraciones al usar múltiples conjuntos de herramientas dentro del mismo equipo de proyecto. Por ejemplo, mi equipo tiene desarrolladores de Java que usan IntelliJ y la mayoría de los desarrolladores de front-end (JSP / CSS / HTML) que usan eclipse. Estamos en el proceso de migrar a los usuarios de Eclipse a IntelliJ debido a algunos complementos de IntelliJ que hemos desarrollado y que brindan soporte extendido para nuestro entorno. No vamos a desarrollar los complementos para múltiples plataformas, por lo que estamos estandarizando IntelliJ en todos los ámbitos.
En términos de archivos específicos, puedo hablar con IntelliJ. Hemos verificado nuestros archivos .ipr y nuestros archivos .iml. No verifique archivos .iws. Si también tiene usuarios de Eclipse, configure su proyecto IntelliJ para leer / almacenar información de dependencia en el archivo .classpath y confírmelo a su VCS.
Para Eclipse, eso sería archivos .classpath y .project.
Mi equipo utiliza Maven, y los desarrolladores no recomiendan controlar los archivos específicos de Eclipse. Debido a que se pueden generar desde Maven, estos archivos son redundantes.
Además, comprobar los archivos específicos del proyecto parece ahorrar tiempo, pero generalmente termina siendo un problema debido a las variaciones en las estaciones de trabajo de los diferentes desarrolladores, lo que da como resultado un tiempo perdido resolviendo conflictos en los archivos específicos de IDE. La única forma de evitarlo es forzar a todos a configurar su entorno de la misma manera, lo que va en contra del enfoque independiente del IDE.
Para cada IDE que tenga más de un desarrollador, ingrese todos los archivos de respaldo. Por qué reinventar la rueda en cada escritorio.
He hecho esto con muchos IDEs diferentes, y aún no he visto un conflicto de nombre de archivo.
De hecho, incluso cuando solo un desarrollador usa un IDE en particular, es una ventaja para él la versión de los archivos de respaldo, por la misma razón que usted versiona los otros archivos en su entorno de desarrollo: historia, diferencias, comentarios, etc.
Por lo general, consideraría esta una mala idea. No estoy seguro de qué tipo de entorno es este (¿tal vez de código abierto?), Pero realmente sería una mierda para admitir varios IDEs. Una cosa que recomendaría si esto es inevitable sería estandarizar sus compilaciones en scripts ant. Si tiene un gran conjunto de dependencias, esta puede ser la forma más fácil de obtener una compilación predecible en todas las plataformas.
Si uno de los IDEs pasa a ser RAD (basado en eclipse), hay una carpeta completa llamada .settings que no desearía incluir en el SCM.
Cambiamos el nombre de nuestros archivos IDE para el registro con una extensión adicional .deletethis o similar. Cuando una persona nueva revisa el proyecto, simplemente le quitan la extensión adicional y están listos para ir. De esta manera, evitamos conflictos de control de fuente con los archivos de proyecto a medida que las personas modifican sus entornos. Y no tiene que preocuparse por educar a los nuevos desarrolladores para que no revisen esos archivos.
Bueno, esa es una pregunta bastante sincera.
Los archivos que no se controlan en el control de origen son archivos que tienen que ver con los IDEs mismos.
Deje que los desarrolladores generen estos archivos.
Si usa Maven, puede generar los archivos como .project y .classpath de .classpath para usted. Eclipse en general es muy fácil de usar con una estructura básica de archivos (con la nueva opción de Java Project ).
Creo que Maven también tiene soporte para Netbeans, aunque no está seguro sobre IntelliJ.
El sitio de Maven es maven.apache.org .
Para obtener más comentarios y respuestas sobre este tema, consulte esta pregunta (¿Cómo maneja diferentes IDE de Java y svn?)