Soporte Multi-IDE en Java para un equipo

Question

¿Cuál es la mejor manera de permitir que un equipo de programadores use Netbeans, Eclipse e IntelliJ en el mismo proyecto, eliminando así el " cual IDE es mejor " pregunta.

¿Qué archivos deben o no deben registrarse en el control del código fuente?

Answer 1

Creo que la mejor manera es hacer que el proceso de construcción sea independiente del IDE. Esto significa que su proyecto no debe confiar 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 scripts de creación o personalizados. Maven es compatible con los IDE de 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 lo más fácil de configurar posible (es decir, al tener carpetas estándar para bibliotecas compartidas y otras dependencias). Cuando trabajé en equipos con múltiples IDE 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, puede que incluso los desarrolladores no se molesten en obtener la última versión del repositorio de control de versiones, ya que creen que configurar el nuevo proyecto es una molestia.

Si su proyecto tiene muchas dependencias de biblioteca, creo que es una buena idea hacer que estén disponibles en formato binario en el repositorio de control de versiones. De esa manera, las personas no tienen que resolver todas las dependencias de las dependencias y así sucesivamente solo para construir un solo proyecto. Sin embargo, esto requiere que tenga a alguien responsable de mantener el " oficial " binarios actualizados siempre que cambien. (Esta es prácticamente la misma filosofía utilizada por el repositorio de Maven, pero los principios pueden aplicarse manualmente incluso cuando no se usa Maven).

Answer 2

Bueno, esa es una pregunta bastante auto respondida.

Los archivos para no ingresar al control de origen son archivos que tienen que ver con los IDE mismos.

Deje que los desarrolladores generen estos archivos.

Si usa Maven, puede generar los archivos como .project de Eclipse y .classpath para usted. Eclipse en general es muy fácil de usar con una estructura de archivos básica (con la nueva opción Java Project ).

Creo que Maven también tiene soporte para Netbeans, aunque no estoy seguro de IntelliJ.

El sitio de Maven es maven.apache.org .

Answer 3

Para cada IDE que tenga más de un desarrollador, registre todos los archivos de soporte. ¿Por qué reinventar la rueda en todos los escritorios?

He hecho esto con muchos IDE diferentes, y todavía tengo que ver un conflicto de nombre de archivo.

De hecho, incluso cuando solo un desarrollador utiliza un IDE particular, es una ventaja para la versión de los archivos de soporte, por la misma razón que los otros archivos en su entorno de desarrollo: historia, dife- rencia, comentarios , etc.

Answer 4

Para Eclipse, serían los archivos .classpath y .project.

Mi equipo utiliza Maven, y se desaconseja a los desarrolladores que comprueben los archivos específicos de Eclipse. Debido a que se pueden generar desde Maven, estos archivos son redundantes.

Además, la verificación de los archivos específicos del proyecto parece que podría ahorrar tiempo, pero por lo general termina siendo una molestia debido a las variaciones en las estaciones de trabajo de los diferentes desarrolladores, lo que resulta en una pérdida de tiempo en la resolución de conflictos en los archivos específicos del IDE. La única manera de evitar eso es obligar a todos a configurar su entorno de la misma manera, lo que va en contra del enfoque agnóstico del IDE.

Answer 5

Hay muchas consideraciones al usar varios 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 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 revisado nuestros archivos .ipr y nuestros archivos .iml. No registrar 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 comprométase con su VCS.

Answer 6

Intencionalmente admitimos múltiples IDE desde el mismo repositorio SVN. Nuestra idea era que queríamos asegurarnos de que, si una nueva persona se unía al equipo o alguien tenía que comenzar a trabajar en una nueva máquina, queríamos que pudieran verificar el código base, importarlo al IDE e inmediatamente tener un trabajo. configuración capaz.

Lo que eso significa en el extremo del desarrollador es que no deben confirmar sus cambios en los archivos IDE. Todo lo demás (por ejemplo, src, test, lib, etc.) se convierte en el conjunto que normalmente actualizamos y confirmamos todos los días.

El beneficio secundario es que hemos eliminado completamente las guerras de IDE aquí: Netbeans y Eclipse personas viven en perfecta armonía (mirando de reojo a la gente de IntelliJ, pero hey ... ;-).

Answer 7

Para obtener más comentarios y respuestas sobre este tema, consulte esta pregunta (¿Cómo maneja diferentes IDE de Java y svn?)

Answer 8

Cambiamos el nombre de nuestros archivos IDE para el registro con una extensión adicional .deletethis o similar. Cuando una nueva persona revisa el proyecto, simplemente le quitan la extensión adicional y están listos para comenzar. De esta manera, evitamos conflictos de control de origen con los archivos del 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.

Answer 9

Por lo general, consideraría esto como una mala idea. No estoy seguro de qué tipo de entorno es este (¿quizás de código abierto?), Pero realmente sería una gran ayuda para soportar múltiples IDE. 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 IDE es RAD (basado en eclipse), hay una carpeta completa llamada .settings que no querría incluir en el SCM.