¿Cómo se manejan diferentes Java IDEs y svn?

¿Cómo se asegura de que puede verificar el código en Eclipse o NetBeans y trabajar allí con él?

Editar: si no está registrando files relacionados con ide, debe reconfigurar buildpath, includes y todo esto, cada vez que finalice la compra del proyecto. No sé, si la ant (especialmente un file de construcción de ant que se crea / exporta desde eclipse) funcionará con otra ide sin problemas.

La respuesta inteligente es "al hacerlo", a less que no esté trabajando con múltiples IDEs, no sabe si realmente está preparado para trabajar con múltiples IDEs. Honesto. 🙂

Siempre he visto varias plataforms como más engorrosas, ya que pueden usar diferentes estándares de encoding (por ejemplo, Windows puede tener el valor pnetworkingeterminado de ISO-8859-1, Linux a UTF-8) – para mí la encoding ha causado más problemas que los IDE.

Algunos pointers más:

  • Es posible que desee ir con Maven ( http://maven.apache.org ), dejar que genere files IDE específicos y nunca comprometerlos con el control de origen.
  • Para asegurarse de que está generando los artefactos correctos, debe tener un server dedicado para build sus entregas (por ejemplo, cruisecontrol), ya sea con la ayuda de ant, maven o cualquier otra herramienta. Estos entregables son los que se testingn fuera de las máquinas de desarrollo. Una excelente forma de hacer que las personas se den count de que existe otro mundo fuera de su propia máquina.
  • Prohibir que cualquier ruta específica de la máquina esté contenida en cualquier file IDE específico que se encuentre en el control de la fuente. Siempre haga reference a las bibliotecas externas por nombres de routes lógicas, preferiblemente que contengan su versión (si no usa maven)

De hecho, mantenemos un Netbeans y un proyecto de Eclipse para nuestro código en SVN en este momento, sin problemas. Los files Netbeans no pisan los files Eclipse. Tenemos nuestros proyectos estructurados así:

sample-project + bin + launches + lib + logs + nbproject + src + java .classpath .project build.xml 

Los puntos más importantes parecen ser:

  • Prohíba cualquier ruta absoluta en los files de proyecto para IDE.
  • Establezca los files del proyecto para generar los files de class en el mismo directory.
  • svn: ignora el directory privado en el directory .nbproject.
  • svn: ignore el directory usado para la salida del file de class de los IDEs y cualquier otro directory generado en time de ejecución como el directory de loggings anterior.
  • Haga que las personas usen ambos de manera consistente para que las diferencias se resuelvan rápidamente.
  • También mantenga un sistema de compilation independiente de IDEs como cruisecontrol.
  • Use UTF-8 y corrija cualquier problema de encoding de inmediato.

Estamos desarrollando en Fedora 9 de 32 bits y 64 bits, Vista y Windows XP y aproximadamente la mitad de los desarrolladores usan un IDE u otro. Algunos usan ambos y cambian de un lado a otro regularmente.

Lo mejor es, probablemente, no comprometer ningún file relacionado con IDE (como el .project de Eclipse), de esa forma todos pueden verificar el proyecto y hacer lo que quiera.

Habiendo dicho eso, creo que la mayoría de los IDEs tienen su propio esquema de file de configuration, así que quizás puedas cometerlo todo sin tener ningún conflicto, pero se siente complicado.

En general estoy de acuerdo con Seldaek, pero también me inclino a decir que al less deberías dar un file que diga cuáles son las dependencies, qué versión de Java usar para comstackr, etc., y cualquier cosa adicional que un NetBeans / El desarrollador de Eclipse podría necesitar comstackr en su IDE.

Actualmente solo utilizamos Eclipse, por lo que enviamos todos los files .classpath .project de Eclipse a svn, que creo que es la mejor solución, porque entonces todos también pueden reproducir errores y qué no, en lugar de preocuparse por los detalles de IDE.

Soy de la filosofía de que la construcción debe hacerse con un enfoque de "mínimo denominador común". Lo que entra en control de fuente es lo que se requiere para hacer la compilation. Mientras desarrollo exclusivamente con Eclipse, mi compilation es con ant en la línea de command.

Con respecto al control de fuente, solo reviso los files que son esenciales para la construcción desde la línea de command. No hay files Eclipse. Cuando configuro una nueva máquina de desarrollo (parece dos veces al año), hace falta un poco de esfuerzo para que Eclipse importe el proyecto de un file de compilation de antis, pero no da miedo. (En teoría, esto debería funcionar igual para otros IDEs, ¿no? ¿Deben poder importar desde la ant?)

También he documentado cómo configurar un entorno de construcción mínimo.

Yo uso maven, y controlo solo el pomo y la fuente.
Después de revisar un proyecto, ejecuto mvn eclipse: eclipse
Le digo a svn que ignore el proyecto generado, etc.

Esto es lo que hago:

  1. Solo mantenga en control de fuente su script de compilation ant y su classpath asociado. Classpath podría ser explícito en la secuencia de commands de la ant, un file de properties o gestionado por ivy.
  2. escriba un objective ant para generar el file Eclipse .classpath del classpath ant
  3. Netbeans usará su script de compilation y classpath, simplemente configúrelo para hacerlo a través de un proyecto de formulario libre.

De esta forma, obtienes scripts de construcción independientes de IDE y felices desarrolladores 🙂

Hay un blog en el sitio de netbeans sobre cómo hacer 3. pero no puedo encontrarlo ahora. He puesto algunas notas sobre cómo hacer lo anterior en mi sitio – text de enlace (rápido y feo, lo siento)

Tenga en count que si usa Ivy (una buena idea) y eclipse, puede sentirse tentado de usar el complemento eclipse ivy. Lo he usado y descubrí que es horriblemente defectuoso y poco confiable. Es mejor usar 2. arriba.