En algunos casos es necesario iniciar el IDE Eclipse utilizando una JDK en lugar de la JRE por defecto. Un caso es, por ejemplo, para poder utilizar todas las funcionalidades del plugin m2eclipse. Veremos cómo cambiar la configuración para usar otra máquina virtual.

Para ello, debemos editar el archivo eclipse.ini que está en el directorio de instalación de Eclipse (bah, en el directorio en donde lo descomprimimos), y agregar el parámetro -vm indicando el ejecutable de la JDK que usará el IDE. Hay algunas cosas a tener en cuenta:

1. El parámetro -vm debe ir solo en una línea, con su valor en la línea siguiente.
2. El valor del parámetro -vm es la ruta hasta el ejecutable (por ejemplo javaw.exe), no es la ruta del directorio que lo contiene.
3. Es importante la ubicación del parámetro -vm. Debe estar ubicado antes del parámetro -vmargs. Todos los parámetros luego de -vmargs serán pasados directamente a la JVM

Yo tengo una JDK en Windows instalada en el directorio D:\Java\jdk1.6.0_17, y éste es mi eclipse.ini:

-startup
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-product
org.eclipse.epp.package.jee.product
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vm
D:/Java/jdk1.6.0_17/bin/javaw.exe
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx512m

Como último punto a destacar, quisiera comentar que toda esta configuración se puede verificar en About Eclipse, en el menú de Help.

http://wiki.eclipse.org/Eclipse.ini
http://tech.karolzielinski.com/m2eclipse-eclipse-is-running-in-a-jre-but-a-jdk-is-required

Al empaquetar un artefacto Java, puede interesarnos agregar información al manifest generado. El manifest es un archivo que se crea dentro de nuestro JAR (en la ruta META-INF/MANIFEST.MF) con información bastante diversa acerca del JAR, en forma de "propiedad: valor". Esta información puede ser acerca de la versión de código empaquetada, del classpath, de la clase que se ejecutará al correr java -jar [archivo.jar] o inclusive propiedades personalizadas que tienen significado para el usuario de ese JAR.

Utilizando Maven podemos generar automáticamente el archivo MANIFEST.MF. Para ello, debemos editar el archivo pom.xml agregando la configuración del manifest al plugin que se encarga de empaquetar nuestro proyecto (maven-jar-plugin). Veamos un ejemplo:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.josearrarte</groupId>
	<artifactId>tests</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<url>http://www.josearrarte.com/blog</url>

	<dependencies>
		<dependency>
			<groupId>commons-dbcp</groupId>
			<artifactId>commons-dbcp</artifactId>
			<version>1.4</version>
		</dependency>
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.6</source>
					<target>1.6</target>
				</configuration>
			</plugin>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-jar-plugin</artifactId>
				<executions>
					<execution>
						<phase>package</phase>
						<goals>
							<goal>jar</goal>
						</goals>
					</execution>
				</executions>
				<configuration>
					<archive>
						<manifest>
							<classpathPrefix>lib</classpathPrefix>
							<addClasspath>true</addClasspath>
							<mainClass>com.josearrarte.demo.MainClass</mainClass>
						</manifest>
						<manifestEntries>
			              <sample_entry>sample_value</sample_entry>
			              <url>${project.url}</url>
			            </manifestEntries>
					</archive>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

Lo más importante del ejemplo está en la parte de configuración del maven-jar-plugin. Ahí tenemos tres elementos configurados:

• mainClass: Se utiliza para determinar qué clase contiene el método main del JAR cuando ejecutamos la JVM con el parámetro -jar [archivo.jar]
• addClasspath: los valores posibles son true o false. Si el valor es true se agregará una entrada Class-Path al manifest, con la lista de JARs de los cuales depende nuestro artefacto (algunos scopes no serán considerados, por ejemplo test)
• classpathPrefix: este elemento de configuración es útil cuando queremos referenciar los JARs de los que depende nuestro artefacto y están en un directorio diferente. Se pueden utilizar paths relativos

Los elementos dentro de sirven para agregar propiedades adicionales al manifest. Se pueden utilizar variables del estilo de ${project.build.finalName} que serán sustituidas sus valores reales. No conozco todas las variables existentes, pero aquí hay una lista que parece bastante completa.

El archivo META-INF/MANIFEST.MF resultante de empaquetar el proyecto será muy similar al siguiente:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: jarrarte
Build-Jdk: 1.6.0_19
Main-Class: com.josearrarte.demo.MainClass
sample_entry: sample_value
url: http://www.josearrarte.com/blog
Class-Path: lib/commons-dbcp-1.4.jar lib/commons-pool-1.5.4.jar

En el pom.xml del proyecto de ejemplo tenemos una dependencia a commons-dbcp, que a su vez depende de commons-pool. Esto se ve reflejado al construir el valor classpath en el manifest, que contiene las dos dependencias.

Referencias

http://tutorialexception.blogspot.com/2009/03/configurar-el-manifest-con-maven-para.html
http://maven.apache.org/
http://maven.apache.org/shared/maven-archiver/examples/classpath.html
http://maven.apache.org/guides/mini/guide-manifest.html
http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
http://java.sun.com/docs/books/tutorial/deployment/jar/modman.html

m2eclipse es un plugin de Eclipse para la integración con Maven. Permite usarlo para manejar, proyectos simples, multi-módulo, ejecutar builds de Maven utilizando la interfaz de Eclipse e interactuar con repositorios de Maven. El plugin ya está bastante maduro, y resulta muy cómodo para trabajar con este tipo de proyectos.

La instalación es bastante simple. Tenemos que agregar el update site, que es http://m2eclipse.sonatype.org/sites/m2e. Hay una única opción para instalar, llamada “Maven Integration for Eclipse (Required)“. Se instalará el core, el editor de POMs y la integración al repositorio de Maven.

En el sitio oficial hay links a videos bastante descriptivos acerca del proceso de instalación, creación de proyectos, etc.

m2eclipse trae un Maven embebido. Si ya tenemos una instalación de Maven configurada y un repositorio local con artefactos descargados podemos aprovecharla, configurando m2eclipse para que haga uso de ella. Para agregar instalaciones de Maven a m2clipse, debemos acceder al menú de preferencias de Eclipse, agregar la instalación seleccionando el directorio en el cual está ubicado y marcarla como la instalación activa:

El plugin cuenta con bastante documentación. Es posible descargar la referencia de m2eclipse en PDF desde éste link (es necesario llenar algunos datos) o leer la documentación on-line aquí. Tiene una FAQ bastante completa, y el blog de m2eclipse es éste.

La página principal del plug-in es http://m2eclipse.sonatype.org/index.html

Si al compilar un proyecto no da errores del tipo: /ruta/al/proyecto/src/main/java/paquete/Clase.java:[48,30] unmappable character for encoding UTF8 y en esa línea tenemos caracteres con tilde, ñ u otros caracteres “problemáticos”, es muy posible que sea necesario cambiar la configuración del encoding a ISO-8859-1 en la sección de maven-compiler-plugin del archivo pom.xml de nuestro proyecto:

<project>
	...
	<build>
		<plugins>
			...
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					...
					<encoding>ISO-8859-1</encoding>
				</configuration>
			</plugin>
		</plugins>
	</build>
	...
</project>

Otra opción es sacar esos caracteres del código fuente, totalmente viable si estamos hablando de comentarios, o utilizar secuencias de escape para representar los caracteres que necesitamos (por ejemplo, ‘\u00F6′ en lugar de ‘ö’)

Espero que a alguien más le sea útil este tip.

Si por alguna razón queremos evitar que Maven ejecute los tests unitarios al invocarlo, podemos agregar el parámetro “-Dmaven.test.skip=true” o “-DskipTests=true” al invocarlo, por ejemplo,

mvn jar -Dmaven.test.skip=true

Si queremos que ejecute los tests pero que ignore los resultados, es decir, que no cancele la ejecución si algún test falla, podemos agregar el parámetro “-Dmaven.test.failure.ignore=true” a la invocación a Maven.

Si tenemos tests unitarios implementados, obviamente no es lo ideal evitar su ejecución, o ignorar los fallos que tengan, pero de tanto en tanto puede ser útil.

Para los tests de integración, que por concepto quizá tengan que interactuar con otros sistemas, tenemos la opción de configurar la exclusión de ciertos archivos, y que los tests contenidos en ellos no se ejecuten automáticamente al correr los goals de test de Maven. Esto se configura en el POM del proyecto, al configurar las opciones del plugin Surefire (ejecución de tests):

<build>
	<plugins>
		[...]
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-surefire-plugin</artifactId>
			<configuration>
				<includes>
					<include>**/*.java</include>
				</includes>
				<excludes>
					<exclude>integrationTests</exclude>
				</excludes>
				<forkMode>never</forkMode>
			</configuration>
		</plugin>
		[...]
	</plugins>
</build>

Para este ejempo planteado, ejecutará todos los tests del directorio correspondiente, excluyendo los que están dentro del directorio integrationTests y sus subdirectorios.

Referencias

http://maven.apache.org/general.html#skip-test
http://maven.apache.org/plugins/maven-surefire-plugin/examples/skipping-test.html
http://maven.apache.org/plugins/maven-surefire-plugin/examples/inclusion-exclusion.html

Para los desearrolladores que utilizamos Maven como herramienta para el manejo de los proyectos y sus dependencias a librerías de terceros, generalmente nos encontramos con la necesidad de agregar una nueva dependencia, pero no tenemos claro cómo se llama el JAR (artifactId), a qué grupo pertenece (groupId) o qué versión deberíamos referenciar. Estos datos son utilizados para agregar un elemento en nuestro pom.xml.

Para encontrar los detalles de estos elementos tenemos algunas opciones en la web que nos facilitan el trabajo. MavenSearch, MVNRepository y MVNBrowser son una especie de directorios de librerías, las que indexan el repositorio central (link) en caso de MVNRepository, y el central más algunos otros para el caso de MVNBrowser (ver lista de repositorios indexados) y MavenSearch (ver lista de repositorios indexados).

¿En qué nos ayudan estas aplicaciones? Nos permiten hacer búsquedas por nombres de artefacto, nombres de grupo e inclusive, en caso de MavenSearch, nos permite utilizar comodines en esa búsqueda, por ejemplo “group:*jboss” para que retorne todos los artefactos del grupo org.jboss, jboss, etc.

Además de la funcionalidad principal, me parece interesante resaltar el POM report de MVNBrowser. Es un validador de las versiones de nuestras dependencias, en el que ingresamos un listado de artefactos tal como se representan en el pom.xml y nos retorna las actualizaciones a las versiones en uso. Por ejemplo, para una entrada así:

<dependencies>
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>4.4</version>
		<scope>test</scope>
	</dependency>
	<dependency>
		<groupId>commons-io</groupId>
		<artifactId>commons-io</artifactId>
		<version>1.4</version>
	</dependency>
	<dependency>
		<groupId>commons-lang</groupId>
		<artifactId>commons-lang</artifactId>
		<version>2.4</version>
	</dependency>
	<dependency>
		<groupId>log4j</groupId>
		<artifactId>log4j</artifactId>
		<version>1.2.14</version>
	</dependency>
</dependencies>

Nos presenta una salida similar a la siguiente captura (le eliminé los ads):

En resumen:

• MavenSearch:
  • Permite búsquedas utilizando comodines
  • Indexa varios repositorios
  • Sitio muy rápido
• MVNBrowser:
  • Indexa varios repositorios
  • POM report, para verificar si existen nuevas versiones de nuestras dependencias
• MVNRepository:
  • Para un determinado artefacto, grafica los cambios de tamaño entre versiones
  • Indexa sólo el repositorio central
  • No se si es casualidad, pero me ha pasado varias veces que el sitio está bajo

Hace unos días un compañero de trabajo yo nos encontramos con una situación un poco extraña utilizando Maven y AspectJ, digna de comaprtirla. En un proyecto Java en el que utilizamos Maven, algunas de las dependencias en el pom.xml eran las siguientes:

<dependency>
	<groupId>aspectj</groupId>
	<artifactId>aspectjrt</artifactId>
	<version>1.5.3</version>
</dependency>
<dependency>
	<groupId>aspectj</groupId>
	<artifactId>aspectjtools</artifactId>
	<version>1.5.3</version>
</dependency>
<dependency>
	<groupId>aspectj</groupId>
	<artifactId>aspectjweaver</artifactId>
	<version>1.5.3</version>
</dependency>

Sin embargo, al hacer un mvn eclipse:eclipse en la PC de mi compañero, esas dependencias no se veían reflejadas en el proyecto de Eclipse. La salida del comando de Maven no mostraba errores, e inclusive bajaba los JARs de AspectJ al repositorio local, y sin embargo, no había rastros de esas dependencias en el Build path del proyecto. En mi PC no había problemas, las dependencias se bajaban y referenciaban de forma correcta.

Probamos diferentes versiones de Maven (2.1.0 y 2.2.0), pero no se solucionó. Probamos diferentes versiones de las dependencias de AspectJ, y tampoco tuvimos suerte. Después de buscar un poco encontramos un par de bugs reportados, en este link, este link y este otro, y comprendimos que el problema venía por el lado del plugin maven-eclipse-plugin de Maven, y no por el lado de nuestro proyecto. Comprobamos que este error se da utlizando las versiones posteriores a la 2.5.1 del plugin (2.6 en adelante), y que las diferencias en nuestros ambientes de desarrollo se daban porque yo tenía configurado un proxy HTTP, que me retornaba una versión vieja del maven-metadata-central.xml del plugin. En cuanto saqué la configuración del proxy del settings.xml de Maven, Maven actualizó los JARs del plugin en mi PC, y ambos ambientes reflejaron el mismo problema.

El problema se da cuando el soporte para AJDT está activado. Para solucionarlo, debemos agregar la línea <ajdtVersion>none</ajdtVersion> a la configuración de maven-eclipse-plugin en el pom.xml de nuestro proyecto:

<project ...>
	...
	<build>
		<plugins>
			...
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-eclipse-plugin</artifactId>
				<configuration>
					...
					<ajdtVersion>none</ajdtVersion>
					...
				</configuration>
			</plugin>
			...
		</plugins>
	</build>
	...
</project>

Referencias

https://fisheye.codehaus.org/browse/MECLIPSE-544
https://fisheye.codehaus.org/browse/MECLIPSE-558
https://bugs.eclipse.org/bugs/show_bug.cgi?id=270554
http://dev.eclipse.org/newslists/news.eclipse.technology.ajdt/msg01933.html

http://maven.apache.org/plugins/maven-eclipse-plugin/examples/ajdt-projects.html

El plugin archetype de Maven nos permite crear un proyecto de Maven 2 a partir de un template existente.

Para crear un proyecto Java simple (directorio de código fuente, directorio de código fuente para tests, clase de ejemplo, clase de test de ejemplo y pom.xml) utilizamos el goal archetype:create en el directorio padre del proyecto, de la siguiente manera:

mvn archetype:create -DgroupId=com.josearrarte -DartifactId=test

Este comando crea el proyecto con un pom como el siguiente:

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.josearrarte</groupId>
  <artifactId>test</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>test</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

La estructura de directorios generada queda:

(root)
|   pom.xml
|
\---src
    +---main
    |   \---java
    |       \---com
    |           \---josearrarte
    |                   App.java
    |
    \---test
        \---java
            \---com
                \---josearrarte
                        AppTest.java

Otros posibles goals del plugin archetype son los siguientes:

• archetype:generate muesta un catálogo de plantillas y pide al usuario que seleccione uno. Luego de un conjunto de pasos variables (según la cantidad de parámetros pedidos al usuario), el plugin se baja la plantilla, procesa los parámetros y genera un projecto Maven.
• archetype:create-from-project crea una nueva plantilla a partir de un proyecto existente.
• archetype:crawl: escanea el repositorio en búsqueda de nuevos templates y actualiza el catálogo

Más info:

• Better builds with Maven (PDF)
• http://maven.apache.org/
• http://maven.apache.org/plugins/maven-archetype-plugin/