2012-03-14 50 views
19

Estamos obteniendo un comportamiento muy extraño en nuestro entorno de desarrollo que es coherente con todos nuestros desarrolladores, los desarrolladores se encuentran en diferentes sistemas operativos.Maven clean + build hace que el proyecto en Eclipse muestre errores hasta que esté limpio en Eclipse

Tenemos más de 20 proyectos maven (3.0.4) en el entorno de desarrollo, todos ellos son proyectos abiertos en Eclipse (Indigo) con sonatype m2e (0.12.0) manejando las dependencias como de costumbre. (m2e 1.0 nos está causando más problemas que soluciones)

De todos nuestros 20 proyectos + hay un proyecto que está actuando raro. Al realizar "mvn clean install" en ese proyecto, aunque maven pase con éxito, causa 4 archivos java (en las pruebas de unidad, si hay alguna diferencia) para mostrar errores en Eclipse.

Los errores de un "SomeNameOfClass cannot be resolved to a type" naturaleza a pesar de abrir el archivo y presionar F3 (declaración abierta) en la referencia de clase errónea encuentra la clase sin ningún problema.

"mvn clean" es el problema, si solo ejecutamos "mvn install" esto no sucede.

El proyecto-> clean de Eclipse borra los errores y todo está bien.

Ésta es no un problema operativo que en realidad me impide trabajar ni nada de eso, puedo resolverlo simplemente mediante la limpieza en Eclipse, que odio haciendo que cada vez y no puedo soportar X roja en mis proyectos, incluso si no tienen ningún efecto.

Solo tengo curiosidad por saber por qué sucede esto, ¿por qué específicamente esas 4 clases? ¿por qué por qué? :)

Gracias

+0

¿Puede dar más precisiones sobre esas clases de prueba? ¿Hay otras clases de prueba que se comporten como se espera? ¿Tienen un camino específico? –

+0

Como se mencionó anteriormente, debería dar más detalles. ¿Se generan esos archivos? – khmarbaise

+0

Los archivos son archivos java normales, no generados. Están sufijos con Test y contienen algunos métodos que se anotan con @Test como las clases de JUnit normales. La clase a la que se hace referencia que se muestra como 'no se puede resolver a un tipo' es abstracta – Enrico

Respuesta

20

Hemos tenido el mismo problema hace un tiempo. Tuvimos más de 20 proyectos dando el mismo tipo de error. De la investigación que hicimos, concluimos que cuando se ejecuta maven clean install, eclipse pierde la pista de los archivos de clase y cree que algunos de ellos no están definidos. La solución que tuvimos es emitir el siguiente en la línea de comandos:

mvn eclipse:clean 
mvn clean install 
mvn eclipse:eclipse 
+5

Si se usa m2e o m2eclipse, mvn eclipse: ... ya no se debe usar. La mejor manera sería hacer una Actualización-Proyecto-Configuración en el menú Contexto de Maven. – khmarbaise

+1

@GETah Si bien lo que está sugiriendo elimina los errores, arruina el .project y .classpath. Esos archivos están en nuestro control de fuente y cambiarlos en cada compilación no es una buena opción. Supongo que podría hacer eso y después de todo realizar un 'git checkout - .project' y' git checkout - .classpath' pero eso parece un poco engorroso. – Enrico

+7

@Enrico Creo que tener la configuración de eclipse bajo control de versión no es una buena idea. Solo debe mantener su código fuente junto con los archivos pom bajo control de fuente. – GETah

0

Esto es ahora posible especificar que el proyecto (s) necesita una actualización sobre la terminación bajo Refresh pestaña en Run configuration. Deberá marcar Refresh resources upon completion y seleccionar el comportamiento a continuación.

Cuestiones relacionadas