2010-09-16 15 views
6

Mi equipo actual se ha estandarizado en NetBeans para todo nuestro desarrollo de Java, y utilizamos los archivos de ANT generados por NetBeans como nuestro proceso de compilación oficial.Los archivos de compilación de NetBeans nunca son correctos

Pero los archivos siempre son incorrectos.

Varios miembros del equipo están utilizando diferentes versiones de NetBeans, y evidentemente, todos ellos generan ligeramente diferentes archivos de "construcción-impl.xml". Por lo tanto, al iniciar IDE, NetBeans regenerará cualquiera de estos archivos que decida que son incorrectos o están desactualizados.

Pero luego (dado que estos archivos están registrados en el control de código fuente, como nuestros scripts de compilación oficiales) los archivos de compilación generalmente no están sincronizados con el repositorio. Si controlo los cambios generados automáticamente desde mi máquina, entonces algún otro imbécil de mi equipo tendrá que sobrescribir su propia copia local de los scripts de compilación, causando que NetBeans se queje de que los archivos están desactualizados y necesitan ser actualizados. regenerado

Principalmente, esto es una molestia. O las diferencias falsas en los guiones de compilación generados automáticamente añaden mucho ruido para examinar cada vez que un desarrollador realiza un checkin. O el IDE constantemente se queja de los scripts de construcción modificados externamente. No puedes ganar

Pero también tienen una molesta sensación constante de que nadie tiene un script de construcción totalmente correcta, y estamos introduciendo indeterminismo en todo el proceso de construcción.

Por lo que yo puedo decir, hay dos posibles soluciones al problema:

1) estandarizar una versión particular de NetBeans. No permita que las personas se actualicen hasta que tomemos una decisión, como equipo, para hacerlo. Y no dejes que la gente se quede atrás en versiones anteriores. Si todos en el equipo usan la misma versión de NB, estos problemas (probablemente) desaparecerán.

2) No revise el script "build-impl.xml" en el control de código fuente. Es generado automáticamente por el IDE y, por lo tanto, es un artefacto de los archivos "build.xml" y "project.xml". Los archivos generados (como los archivos ".class") no deben registrarse en el control de origen, sino que deben regenerarse durante el proceso de compilación. Averigüe qué mecanismo utiliza NetBeans para generar el archivo "build-impl.xml" y ejecute el mismo mecanismo en nuestro servidor de compilación. ¿Esto significa que nuestro servidor de compilación debería confiar en la GUI de NetBeans? Espero que no.

¿Qué piensan? ¿Cuál es la forma correcta de resolver este problema?

Respuesta

4

Creo que hay que ir por el número 1, tiene todos sus compañeros utilizan la misma versión de NetBeans. En mi trabajo también desarrollamos en NetBeans, pero todos usamos la misma versión y actualizamos al mismo tiempo. Los últimos dos años que he estado usando NetBeans, he experimentado que varias cosas cambian con cada versión (menos hoy en día), desde la configuración hasta los archivos de forma, así que creo que es mejor minimizar los posibles problemas con las diferentes versiones.

También es más fácil señalar el origen de un error si todos comparten el mismo entorno.

0

¿Qué pasa con el uso de una acumulación de eso imp.xml.template versionados e ignorando la acumulación imp.xml con respecto a control de código fuente. Los usuarios pueden 'fácilmente' fusionar sus archivos de compilación 'personales' con los de la versión. También es capaz de propagar los cambios a través de 'build-imp.xml.template' a sus compañeros de trabajo.

Puede echar un vistazo a Understand MacroDef Tasks in Netbeans Build Files.

0

Según mi opinión las siguientes carpetas no se añadirán al control de código fuente:

  1. acumulación (que contiene los archivos .class)
  2. dist (que contiene los archivos JAR construidos)
  3. nbproject/privada (mientras que contiene archivos específicos de la máquina local)

No nos comprometemos.archivos de clase, de hecho todo lo que se genera desde el proceso de compilación de NetBeans a un repositorio de control de origen.

Todas las personalizaciones locales se realizarán en el archivo build.xml guardado en el directorio raíz del proyecto y esas personalizaciones, si son por desarrollador, no se volverán a enviar al repositorio. El nbproject/build-impl.xml no se tocará una vez creado por el generador de proyectos NetBeans.

con respecto Tushar

Cuestiones relacionadas