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

Question

¿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 archivos relacionados con ide, debe reconfigurar buildpath, includes y todo esto, cada vez que finalice la compra del proyecto. No sé, si la hormiga (especialmente un archivo de construcción de hormiga que se crea/exporta desde eclipse) funcionará con otra ide sin problemas.

Answer 1

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

Siempre he visto varias plataformas como más engorrosas, ya que pueden usar diferentes estándares de codificación (p. Ej., Windows puede ser por defecto ISO-8859-1, Linux a UTF-8) - la codificación ha causado más problemas que IDEs.

Algunos más punteros:

• Es posible que desee ir con Maven (http://maven.apache.org), dejar que genere archivos específicos IDE y nunca las aprenden de control de código fuente.
• Para asegurarse de que está generando los artefactos correctos, debe tener un servidor dedicado para compilar sus entregas (por ejemplo, cruisecontrol), ya sea con la ayuda de hormiga, maven o cualquier otra herramienta. Estos entregables son los que se prueban fuera de las máquinas de desarrollo. Una excelente forma de hacer que las personas se den cuenta 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 archivo IDE específico que se encuentre en el control de código fuente. Siempre haga referencia a las bibliotecas externas por nombres de ruta lógicos, preferiblemente que contengan su versión (si no usa maven)

Answer 2

Lo mejor es probablemente no confirmar cualquier archivo relacionado con IDE (como el .project de Eclipse), de esa forma todos pueden verificar el proyecto y hacer lo que quiera.

Dicho esto, supongo que la mayoría de los IDEs tienen su propio esquema de archivo de configuración, así que tal vez pueda comprometerlo todo sin tener ningún conflicto, pero se siente complicado.

Answer 3

En general estoy de acuerdo con seldaek, pero también me inclino a decir que al menos deberías dar un archivo que diga cuáles son las dependencias, qué versión de Java usar para compilar, etc. y cualquier cosa extra que un desarrollador de NetBeans/Eclipse podría necesitar compilar en su IDE.

Actualmente solo utilizamos Eclipse, por lo que enviamos todos los archivos .classpath .project de Eclipse a svn, que creo que es la mejor solución porque entonces todos también pueden reproducir errores y lo que no es fácil en lugar de molestarse con IDE específicos .

Answer 4

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 compilación. Mientras desarrollo exclusivamente con Eclipse, mi compilación es con hormiga en la línea de comando.

Con respecto al control de fuente, solo reviso los archivos que son esenciales para la compilación desde la línea de comandos. No hay archivos 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 archivo de compilación de antis, pero no da miedo. (En teoría, esto debería funcionar igual para otros IDEs, no? Surly deben ser capaces de importar de hormiga?)

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

Answer 5

Uso maven, y registro solo en la fuente pom &.
Después de comprobar a cabo un proyecto, corro mvn eclipse: eclipse de
le digo svn ignorar el .project generado, etc.

Answer 6

En realidad mantenemos una Netbeans y un proyecto de Eclipse para nuestro código en el SVN en este momento sin problemas en absoluto. Los archivos Netbeans no pisan los archivos Eclipse. Tenemos nuestros proyectos estructurados de la siguiente manera:

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

Los puntos más importantes parecen ser:

• prohibir cualquier rutas absolutas en los archivos del proyecto, ya sea para IDE.
• Establezca los archivos de proyecto para generar los archivos de clase en el mismo directorio.
• svn: ignore el directorio privado en el directorio .nbproject .
• svn: ignore el directorio utilizado para la salida del archivo de clase de los IDEs y cualquier otro directorio generado en tiempo de ejecución como el directorio de registros anterior.
• Haga que las personas usen tanto consistentemente para que las diferencias se resuelvan rápidamente.
• También mantener un sistema de compilación independiente de los IDEs como cruisecontrol.
• Utilice UTF-8 y corrija cualquier problema de codificación inmediatamente.

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.

Answer 7

Aquí es lo que hago:

1. sólo mantienen en control de origen de su script de construcción Ant y ruta de clase asociada. Classpath podría ser explícito en la secuencia de comandos de la hormiga, un archivo de propiedades o gestionado por ivy.
2. escribe un objetivo ant para generar el archivo .classpath de Eclipse de classpath
3. Netbeans usará tu script de compilación y classpath, solo configúralo para hacerlo a través de un proyecto de formulario libre.

esta manera se obtiene IDE scripts de construcción independiente y desarrolladores feliz :)

Hay un blog en el sitio de NetBeans sobre cómo hacerlo 3. Pero no puedo encontrar ahora mismo. He puesto algunas notas sobre cómo hacer lo anterior en mi sitio - link text (rápido y feo, lo siento)

Tenga en cuenta que si está usando Ivy (una buena idea) y eclipse puede que tenga la tentación de usar el complemento eclipse ivy. Lo he usado y he descubierto que es horriblemente defectuoso y poco confiable. Es mejor usar 2. arriba.