Solución de problemas comunes con la integración de maven en Eclipse Luna.

0
40785

Solución de problemas comunes con la integración de maven en Eclipse.

0. Índice de contenidos.


1. Introducción

En este tutorial vamos a responder a pequeñas, pero importantes, cuestiones relacionadas con la integración de un
proyecto que dispone el soporte de maven en Eclipse.

Eclipse proporciona ahora, de forma nativa, el soporte para gestionar las dependencias de las librerías
de un proyecto maven; para ello, proporciona una preinstalación de los plugins de m2e y m2e-wtp.

Con versiones anteriores de eclipse los problemas solían ser del soporte del plugin q4e para wtp o
tener instalado el plugin de m2e, pero no el de m2e-wtp, con lo que funcionaba la gestión de dependencias
de los módulos jars, pero no la de los módulos war; o funcionaba pero no facetaba el proyecto con lo que
no se podían desplegar en un servidor.

Con las últimas versiones de Eclipse esos problemas han desaparecido pero siguien otros y pueden surgir nuevos,
y eso es justo lo que vamos a ver en este tutorial.

2. Entorno.

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15′ (2.3 GHz Intel Core i7, 16GB DDR3).
  • Sistema Operativo: Mac OS Mavericks 10.9.4
  • Eclipse Luna.
  • Apache Maven 3.2.3


3. Despliegue del artefacto empaquetado en el servidor local.

En este punto vamos a hablar tanto del plugin de maven para eclipse como de su integración con el plugin de Apache
Tomcat o de cualquier otro plugin que nos permita desplegar nuestro proyecto web en un servidor de aplicaciones.

Según cómo configuremos el servidor local el despliegue se realiza en el directorio de despliegue del servidor o en
el directorio del plugin del servidor en el directorio de instalación de Eclipse, véase:

/WORKSPACE/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps

Es frecuente, que se produzcan errores de arranque de tu aplicación a causa de la inexistencia de ficheros de propiedades
o de dependencias de librerías que aunque sí existen:

  • en el workspace,
  • dentro del directorio de fuentes,
  • como dependencia gestionada por maven, y
  • dentro del directorio de build, esto es, en el directorio target

no se trasladan al directorio de despliegue de la aplicación en local, esto es, al directorio wtpwebapps del .metadata
o al directorio de despliegue del propio servidor, según la configuración antes vista.

En este punto, en el que sabemos que el fichero o la dependencia sí existe,
lo primero es comprobar que efectivamente el fichero se encuentre también en el directorio de despliegue.
Si no se encuentra, las causas pueden ser varias:

  • que exista un problema en la configuración de algún fichero, por ejemplo, en el pom.xml del proyecto;
    solemos obviar las marcas de error y solucionarlas, del modo que sea, puede solventar este otro problema colateral,
  • idem con problemas producidos en el «Java Build Path», tendremos que solventarlo primero
  • aunque el más frecuente es el más simple y recurrente, sobre todo en plataformas windows, atento!

    teniendo el servidor arrancado, no se ha parado de forma normal y el proceso de lectura del servidor
    sobre el directorio de despliegue está aún activo, lo que impide la escritura sobre el mismo

Este último supuesto es el más probable, como comentaba en entornos windows, y se puede solucionar comprobando con
una herramienta de tipo processExplorer
examinando los hilos de ejecución que apuntan a un directorio de sistema. Incluso desde la propia herramienta se puede
terminar con el proceso solucionando el problema.

Este problema es común en todas las versiones y puede reproducirse, o no, básicamente en función de cómo se
produzcan las paradas del servidor local.


4. Soporte para la compilación con AspectJ.

Esta segunda tipología de error sí puede ser nueva; imagina que hasta ahora usabas un plugin de maven para la
construcción o empaquetación del proyecto y, tras instalar la última versión de Eclipse Luna, comienza a dar problemas
de incompatibilidad. Aquello que venía cubriendo el ciclo de vida de maven en Eclipse, a partir de ahora ya no lo cubre.

Vamos a imaginar que el plugin que comienza a darnos problemas es el de aspectJ

	<properties>
		<aspectj.version>1.8.2</aspectj.version> <!-- specify your version -->
	</properties>
	
	<build>
		<plugins>
			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>aspectj-maven-plugin</artifactId>
				<version>1.7</version>
				<dependencies>
					<dependency>
						<groupId>org.aspectj</groupId>
						<artifactId>aspectjtools</artifactId>
						<version>${aspectj.version}</version>
					</dependency>
				</dependencies>
			       <executions>
			          <execution>
			            <goals>
			              <goal>compile</goal>
			              <goal>test-compile</goal>
			            </goals>
			          </execution>
			        </executions>
            <configuration>
                <complianceLevel>1.7</complianceLevel>
                <encoding>${project.build.sourceEncoding}</encoding>
                <source>1.7</source>
                <target>1.7</target>
            </configuration>
			</plugin>
		</plugins>
	</build>

En este caso, lo podemos solucionar instalando un plugin de maven que proporciona el soporte necesario
para que forme parte del ciclo de vida de maven en Eclipse.

Usando el siguiente sitio http://download.eclipse.org/tools/ajdt/43/update y con estos pasos, podemos
proceder a su instalación:

Seleccionando estos paquetes:

Y, a continuación con el siguiente

Con ello nuestros problemas comenzarán a desaparecer.


5. Plugin no soportado en el ciclo de vida de maven en Eclipse.

Ahora un segundo plugin, el de jacoco, que venía funcionando hasta ahora y con la nueva instalación ha dejado de funcionar;
imaginemos que, en este caso, no disponemos de un plugin de maven para eclipse que instalar y comienza a dar problemas
esta simple configuración:

	<build>
		<plugins>
			<plugin>
				<groupId>org.jacoco</groupId>
				<artifactId>jacoco-maven-plugin</artifactId>
				<version>0.6.5.201403032054</version>
				<configuration>
					<propertyName>jacoco.agent.argLine</propertyName>
					<destFile>${sonar.jacoco.itReportPath}</destFile>
					<append>true</append>
				</configuration>
				<executions>
					<execution>
						<id>agent</id>
						<goals>
							<goal>prepare-agent</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
			<plugin>
				<artifactId>maven-failsafe-plugin</artifactId>
				<version>2.14.1</version>
				<dependencies>
					<dependency>
						<groupId>org.apache.maven.surefire</groupId>
						<artifactId>surefire-junit47</artifactId>
						<version>2.14.1</version>
					</dependency>
				</dependencies>
				<configuration>
					<argLine>${jacoco.agent.argLine}</argLine>
					<testFailureIgnore>true</testFailureIgnore>
					<reportsDirectory>${project.build.directory}/surefire-reports</reportsDirectory>
				</configuration>
				<executions>
					<execution>
						<goals>
							<goal>integration-test</goal>
							<goal>verify</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>

Lo que podemos hacer es habilitar un plugin dentro de la gestión de plugins de maven, en el propio pom.xml,
para ignorar la ejecución del plugin de jacoco dentro de la fase correspondiente de ejecución del mismo, en el ciclo de
vida de maven, dentro de eclispe.

  <build>
	<pluginManagement>
        <plugins>
            <!--This plugin's configuration is used to store Eclipse m2e settings only.
                It has no influence on the Maven build itself.-->
            <plugin>
                <groupId>org.eclipse.m2e</groupId>
                <artifactId>lifecycle-mapping</artifactId>
                <version>1.0.0</version>
                <configuration>
                    <lifecycleMappingMetadata>
                        <pluginExecutions>
                            <pluginExecution>
                                <pluginExecutionFilter>
                                    <groupId>org.jacoco</groupId>
                                    <artifactId>jacoco-maven-plugin</artifactId>
                                    <versionRange>[0.5,)
                                    </versionRange>
                                    <goals>
                                        <goal>prepare-agent</goal>
                                    </goals>
                                </pluginExecutionFilter>
                                <action>
                                    <!-- m2e doesn't know what to do with jacoco,
                                        let's ignore it or annoying error markers appear
                                        see http://wiki.eclipse.org/M2E_plugin_execution_not_covered
                                     -->
                                    <ignore></ignore>
                                </action>
                            </pluginExecution>
                        </pluginExecutions>
                    </lifecycleMappingMetadata>
                </configuration>
            </plugin>
        </plugins>
    </pluginManagement>
  </build>

Tiene que coincidir el número de versión con el patrón y con ello desaparecerán los errores en el pom.xml
y en el proyecto por esta causa.

Claro está que esta configuración no vamos a disponer de la ejecución del plugin de jacoco, puesto
que la estamos ignorando; lo normal no es ejecutar el ciclo de tests de integración desde Eclipse sino más bien
por línea de comandos con


6. Referencias.


7. Conclusiones.

Aquí seguimos, intentando eliminar el rojo en los proyectos de nuestro Eclipse 😉

Un saludo.

Jose

jmsanchez@autentia.com

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad