m2eclipse
Esta posibilidad está disponible bajo el menú Import.

Por ejemplo, pulsa el botón derecho en una fichero jar de tu workspace, selecciona Import –> Maven –> Install or deploy an artifact to a Maven repository.

vía

Maven
Ultimamente estaba teniendo problemas al arrancar mi Eclipse (versión 3.5.0) ya que el plugin m2eclipse (versión 0.9.9 – 20090820) intentaba actualizar los índices de los repositorios de Maven y fallaba en el intento dando siempre un NullPointerException.

Una posible solución, aunque tal vez no sea la mejor, consiste en limpiar la caché de nexus que utiliza el plugin, de tal modo que vuelva a generar todos los índices. Para ello nada mas facil que eliminar la carptea:

  • <workspace>\.metadata\.plugins\org.maven.ide.eclipse\nexus

estando Eclipse cerrado.

Tras esto, deberías poder actualizar los índices sin problema.

vía

Maven
Para poder conpilar con el SDK de Flex usando Maven, existen varios plugins. Entre ellos:

Pero antes de poder utilizar ningudo de ellos, lo primero es tener disponible en nuestro repositorio de Maven una copia del SDK de Flex (copia no disponible en los repositorios públicos por no ser de libre distribución).

Para consiguir instalar el SDK de Flex de forma sencilla en nuestro repositorio, dentro de flex-mojos, existe el mojo install-mojo que mediante el siguiente comando nos permite realizar la instalación en nuestro repositorio local:

mvn info.flex-mojos:install-mojo:2.0M6:install-sdk -Dflex.sdk.folder="C:\software\flex_sdk_3" -Dversion=3.1.0.2710

El anterior comando nos instalará el SDK situado en “C:\software\flex_sdk_3” en el repositorio y nos dejará disponibles a partir de ese momento varios artefactos, siendo los dos más importantes:

<dependency>
<groupId>com.adobe.flex.framework</groupId>
<artifactId>playerglobal</artifactId>
<version>3.1.0.2710</version>
<type>swc</type>
<scope>external</scope>
</dependency>

y

<dependency>
<groupId>com.adobe.flex.framework</groupId>
<artifactId>flex-framework</artifactId>
<version>3.1.0.2710</version>
<type>pom</type>
</dependency>

El primero es el compilador. Cosas de Java. JARs.
El segundo es el framework flex. Cosa de Flex. SWCs.

NOTA: La dependencia flex-framework es la que se debería utilizar como dependencia de tu proyecto. Ambas dependencias no se deberían utilizar juntas y por tanto, si aparecen ambas en el el mismo bloque de dependencias de tu proyecto es muy probable que algo vaya mal.

Ahora bien, existe un problema y es que cuando intentamos compilar la aplicación obtenemos un error de Maven indicando que no puede resolver una dependencia a playerglobal. Esto es devido a que la instalación que acabamos de realizar crea en el repositorio de maven (.m2\repository\com\adobe\flex\framework\playerglobal) un directorio con el nombre “9-3.1.0.2710” en vez del esperado “3.1.0.2710“. La solución pasa por renombrar el directorio (esto es, eliminar el “9-“) y renombrar el .pom y el .swc contenidos en dicho directorio (para que su versión no contenga el “9-“), y editar el archivo playerglobal-3.1.0.2710.pom corrigiendo la <version>.

Algunos enlaces de interés

Install-mojo
install mojo – makes playerglobal version have “9-” in front of it?
Maven and Flex Builder tutorial

Maven
Tenía un proyecto construido con maven en el que mostraba en la cabecera el número de versión pero necesitaba además mostrar la fecha y hora en la que se construyó dicha versión (y así poder tener un seguimiento más preciso de incidencias asociadas a una versión y fecha dadas).

La versión y fecha de la misma, se muestran en una jsp, recuperando el valor a mostrar de un archivo .properties donde defino la propiedad del siguiente modo:

label.version = Ver. ${project.version} (${build.time})

Este fichero se encuentra alojado en src/main/resources y será procesado por Maven, realizando la sustitución, al realizar un process-resources.

El valor de “project.version” ya está definido en el propio pom.

Para conseguir el valor de build.time definiremos una tarea ANT usando el plugin de maven correspondiente, del siguiente modo:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>generate-resources
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<mkdir dir=”${project.build.directory}”/>
<tstamp>
<format property=”last.updated” pattern=”dd/MM/yyyy”/>
</tstamp>
<echo file=”${basedir}/target/filter.properties” message=”build.time=${last.updated}”/>
</tasks>
</configuration>
</execution>
</executions>
</plugin>

Ahora solamente nos falta especificar que los recursos sean filtrados y la ubicación del fichero utilizado para realizar el mismo:

<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>

<filters>
<filter>${basedir}/target/filter.properties</filter>
</filters>

Algunos enlaces de interés

Cookbook: How To Add Build Time To A JAR Manifest?
Maven: Adding Custom Attributes and Build Timestamp to Manifest

Maven
En el archivo settings.xml (bien en el del usuario o en el global de maven) crearemos un perfil que defina unas variables de entorno con el path de los diferentes compiladores que utilizamos:

<profiles>
<profile>
<id>dev</id>
<properties>
<JAVA_1_6_HOME>C:\software\jdk1.6</JAVA_1_6_HOME>
<JAVA_1_5_HOME>C:\software\jdk1.5</JAVA_1_5_HOME>
<JAVA_1_4_HOME>C:\software\jdk1.4</JAVA_1_4_HOME>
<JAVA_1_3_HOME>C:\software\jdk1.3</JAVA_1_3_HOME>
<JAVA_1_2_HOME>C:\software\jdk1.2</JAVA_1_2_HOME>
</properties>
</profile>
</profiles>

<activeProfiles>
<activeProfile>dev</activeProfile>
</activeProfiles>

Ahora, en el pom.xml del proyecto, configuraremos el plugin de compilación para que utilice un compilador específico:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.4</source>
<target>1.4</target>
<fork>true</fork>
<executable>${JAVA_1_4_HOME}/bin/javac</executable>
</configuration>
</plugin>

Nota: La propiedad fork es necesaria porque en caso contrario maven utiliza el mismo proceso con el que se arranca el propio plugin y por tanto la misma JDK, independientemente de la que hayamos indicado en la configuración.

Algunos enlaces de interés

Compiling Sources Using A Different JDK

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

%d personas les gusta esto: