plugin - ¿Cómo se manejan diferentes Java IDEs y svn?
svn repository eclipse (7)
¿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.
De hecho, mantenemos un Netbeans y un proyecto de Eclipse para nuestro código en SVN en este momento, sin problemas. Los archivos Netbeans no pisan los archivos 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 archivos de proyecto para IDE.
- Establezca los archivos del proyecto para generar los archivos de clase en el mismo directorio.
- svn: ignora el directorio privado en el directorio .nbproject.
- svn: ignore el directorio usado 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 ambos de manera consistente para que las diferencias se resuelvan rápidamente.
- También mantenga un sistema de compilación independiente de IDEs como cruisecontrol.
- Use UTF-8 y corrija cualquier problema de codificación 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.
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 adicional que un NetBeans / El desarrollador de 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 qué no, en lugar de preocuparse por los detalles de IDE.
La respuesta inteligente es "al hacerlo", a menos 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 plataformas como más engorrosas, ya que pueden usar diferentes estándares de codificación (por ejemplo, Windows puede tener el valor predeterminado de ISO-8859-1, Linux a UTF-8) - para mí la codificación ha causado más problemas que los IDE.
Algunos punteros más:
- Es posible que desee ir con Maven ( http://maven.apache.org ), dejar que genere archivos IDE específicos y nunca comprometerlos con el control de origen.
- Para asegurarse de que está generando los artefactos correctos, debe tener un servidor dedicado para construir 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 la fuente. Siempre haga referencia a las bibliotecas externas por nombres de rutas lógicas, preferiblemente que contengan su versión (si no usa maven)
Lo mejor es, probablemente, no comprometer ningún archivo 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 archivo de configuración, así que quizás puedas cometerlo todo sin tener ningún conflicto, pero se siente complicado.
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 construcción desde la línea de comando. 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? ¿Deben poder importar desde la hormiga?)
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:
- Solo mantenga en control de fuente su script de compilación ant y su classpath asociado. Classpath podría ser explícito en la secuencia de comandos de la hormiga, un archivo de propiedades o gestionado por ivy.
- escriba un objetivo ant para generar el archivo Eclipse .classpath del classpath ant
- Netbeans usará su script de compilación 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 - texto de enlace (rápido y feo, lo siento)
Tenga en cuenta 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.