Instalación de Apache Maven en Ubuntu 12.04LTS

En esta ocasión se me dio por instalar Maven en mi ubuntu, asi que aquí les dejo los pasos que seguí.

Versión de ubuntu 12.04LTS
Versión de apache maven 3.0.4
Versión de java sdk 6u35

Descargar el binario (Binary tar.gz) de Maven desde el siguiente enlace:

http://maven.apache.org/download.html

Desempaquetar el binario en un directorio con permisos de ejecución.

Ingresar via “Terminal” al directorio en el que desempaquetamos el binario y ejecutamos la sentencia “./mvn -version”, prestemos atención al resultado:

Warning: JAVA_HOME environment variable is not set.Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: /home/armando/apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: es_PE, platform encoding: UTF-8
OS name: "linux", version: "3.2.0-31-generic", arch: "amd64", family: "unix"

Si bien todo parece andar casi OK, debemos setear la variable “JAVA_HOME” para evitar cualquier problema de ejecución de tareas, adicionalmente, prefiero usar el JDK de 0racle, en lugar del OPENSDK (cuestión de gustos por ahora) para las labores de desarrollo, por ello será necesario descargar el binario correspondiente a java desde la página de 0racle.

Para iniciar la descarga del binario (jdk-6u35-linux-x64.bin) nos dirigimos al siguiente enlace:

http://www.oracle.com/technetwork/java/javase/downloads/

y seguimos las instrucciones para “Self Extracting Linux 64 bits” (porque uso la versión para 64 bits) que encontramos en este otro enlace:

http://www.oracle.com/technetwork/java/javase/index-137561.html#linux

Una vez que ya tengamos instalado al java, estableceremos la variable JAVA_HOME de la siguiente manera:

export JAVA_HOME=/home/armando/jdk6u35/jdk1.6.0_35/

Luego, volvemos a ejecutar la sentencia “./mvn -version” y obtendremos un resultado similar al que sigue:

Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: /home/armando/apache-maven-3.0.4
Java version: 1.6.0_35, vendor: Sun Microsystems Inc.
Java home: /home/armando/jdk6u35/jdk1.6.0_35/jre
Default locale: es_PE, platform encoding: UTF-8
OS name: "linux", version: "3.2.0-31-generic", arch: "amd64", family: "unix"

Y con esto ya estaríamos listo para empezar a usar Maven.

*************** Actualización 15:22hrs ***************

Para facilitar las cosas agregaremos algunas variables al sistema:

Abrimos el archivo “/etc/environment” y agregamos las siguientes lineas:

M2_HOME=”/home/armando/apache-maven-3.0.4”
MAVEN_HOME=”/home/armando/apache-maven-3.0.4”
M2=”/home/armando/apache-maven-3.0.4/bin”

Luego, modificamos la linea superior correspondiente al PATH:

PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/armando/apache-maven-3.0.4/bin”

Guardamos y por si acaso ejecutamos la siguiente sentencia para asegurarnos que se refleja el cambio:

echo $PATH

Si por a o b no aparece la modificación que le hicimos al PATH ejecutamos la siguiente sentencia:

export PATH=$PATH:/home/armando/apache-maven-3.0.4/bin

Y con esto ya podemos ejecutar el comando “mvn” desde cualquier directorio.

Creando el atajo "Android Project" en mi Eclipse

Por defecto, y a pesar de que le instalé el plugin del SDK de Android, cada vez que quería crear un nuevo proyecto debía ir a "Menu File > New > Project... > Android > Android Project". Un poco largo verdad? Bueno con algunos simples pasos podemos crear un atajo para solo tener que pulsar "Menu File > New > Android Project".

Vamos a "Menu Window > Customize Perspective..."

Una vez alli iremos a la pestaña "Shortcuts" y seleccionaremos "Android Project" como aparece en la figura; y eso es todo.

...Ya podemos seleccionar "Android Project" desde la opción "New".

PRECONEISC - Presentacion sobre Integración Continua

El día de hoy participé como invitado en el evento PRE CONEISC en Cañete, tuve la oportunidad de participar como ponente sobre "El desarrollo potenciado con la Integración Continua"

Integracion continua

View more presentations from Armando Picon.

[MindMap] Continuous Integration - Capitulo 1

Bueno empecé a leer el libro Continuous Integration - Improving Software Quality and Reducing Risk de Paul M. Duvall; y a medida que vaya leyendo cada capitulo estaré subiendo un mapa mental al respecto.

Simplificando tareas con Maven...

En la consultora en la que estuve trabajando hace poco, tuvimos la oportunidad de emplear una herramienta que nos permitió ahorrar tiempo en la tarea de configuración de nuestros proyectos. Esta herramienta es Maven.

Maven es una herramienta para la gestión y configuración de proyectos Java. Una de sus fortalezas radica en un archivo llamado pom (Project Object Model); este archivito guarda los datos relacionados a la configuración y dependencias que empleará la aplicación.

Podemos encontrar que al crear un nuevo proyecto Maven automáticamente genera una estructura de source folders y paquetes que nos permite separar las clases que corresponden a la aplicación en sí de las que pertenecen a nuestras pruebas.

Sobre la gestión de las dependencias me encantó que podíamos determinar el scope de cada dependencia, por ejemplo, podía indicar que mi librería de log4j esté presente durante mis pruebas y que no esté presente al generar mi empaquetado final. También, encontramos que la descarga de dependencias declaradas se efectúa de manera automática a un repositorio local, lo cual nos permite centralizarlas y así evitar el ocupar espacio innecesario con multiples copias, cada una de ellas para un proyecto en particular.

Enlaces:
Apache Maven Project - Página del proyecto.

The Maven 2 POM demystified - Interesante artículo para comprender la importancia del archivo POM.

JUnit... probando sale mejor

En estos días estoy asistiendo a una capacitación interna sobre Buenas Practicas en el Desarrollo de Software.

El martes pudimos trabajar con JUnit, no es la primera vez que trabajo con dicho utilitario, pero el recordatorio me ha caído como anillo al dedo.

Cada vez que programamos un método lo hacemos para que cumpla con una función en particular, y por tanto, siempre queremos que el resultado se de tal como lo esperamos. Entonces, bajo esta premisa, necesitaríamos ir preparando casos de pruebas, a fin de que, al finalizar la implementación, podamos verificar que lo que hemos hecho cumple su cometido. Esta necesidad de nos lleva al uso de esta herramienta.

Recuerdo, que cuando estaba en el instituto (y bueno, muchos programadores novatos lo hacen suelen hacer) solíamos escribir nuestro método "main" para poder hacer nuestras pruebas. Realmente, esto no ayudaba mucho porque las pruebas que intentábamos realizar eran algo flojas y poco consistentes, además de que veíamos nuestras clases con líneas de código que en realidad no debían estar allí.

Con JUnit, tenemos la posibilidad de probar nuestras clases sin tener que modificarlas para este fin. Adicionalmente, gracias a la integración con Eclipse y Ant, podemos ejecutar los casos de prueba (previamente elaborados) en cualquier momento dentro de nuestro desarrollo, de manera que podemos verificar si los métodos que implementamos cumplen adecuadamente con los requerimiento u objetivos trazados.

Puede ser que más de uno diga "no tengo tiempo para hacer ello" o "toma mucho tiempo elaborar los casos de prueba!", sin embargo, los invito a reflexionar y contabilizar sobre el tiempo que demoran tratando de hallar la causa de un problema, que en muchas ocasiones son provocados por errores humanos.

Filtro de objetos con un atributo repetido

Escenario
Se retorna una colección de objetos proveniente de los WebServices y se requiere filtrar, la colección, de forma tal que solo la primera ocurrencia de cada valor atributo repetido quede dentro de la colección. Eliminar los demás duplicados.

Solución 1 - No muy buena
Al principio yo planteé controlar la duplicidad de objetos a través de un flag y una segunda colección de objetos a la cual enviar los objetos. A continuación les pongo mi solución:

List tempCommActions = dataAccessService.getCommercialActions(userLoginId, cic);
List commercialActions = null;
        if (tempCommActions != null)
        {
            commercialActions = new ArrayList();
            boolean flag = true;
            for (int i = 0; i < tempCommActions.size(); i++)
            {
                CommercialAction bean1 = (CommercialAction) tempCommActions.get(i);
                for (int j = 0; j < commercialActions.size(); j++)
                {
                    CommercialAction bean2 = (CommercialAction) commercialActions.get(j);
                    if (bean1.getCampaignCode().equals(bean2.getCampaignCode()))
                    {
                        flag = false;
                        break;
                    }
                }
                if (flag)
                {
                    commercialActions.add(bean1);
                }
            }
        }

Esta solución no termina siendo muy eficiente por la cantidad de objetos que se manejan, además de las reiteradas iteraciones a las listas.

Solución 2 - Mejor
Pero, consultando con uno de mis compañeros... encontramos una mejor manera de implementar esta solución. Para la cual empleamos un iterator para recorrer la lista y un objeto de tipo Set que nos serviría para ir guardando el atributo que comparamos.

        List commercialActions = dataAccessService.getCommercialActions(userLoginId, cic);

        Set visitedCampaignCodes = new HashSet();        
        for (Iterator iterator = commercialActions.iterator(); iterator.hasNext();)
        {
            CommercialAction commercialAction = (CommercialAction) iterator.next();
            if (visitedCampaignCodes.contains(commercialAction.getCampaignCode()))
            {
                iterator.remove();
            }
            else
            {
                visitedCampaignCodes.add(commercialAction.getCampaignCode());
            }
        } 

Genial no? Y eso que mi compañero agregó... "es posible que haya una mejor solución aun". :P

WebSphere Portlet Factory - Carga y lectura de archivos en el browser

El amigo Andres ha publicado una presentación sobre "Cómo cargar PDF en un portlet haciendo uso del WebSphere Portlet Factory".

Resolviendo el error "Unsupported major.minor version 49.0"

El día de hoy mientras intentaba correr una pequeña aplicación Java me salió el siguiente error:

Unsupported major.minor version 49.0

Al principio pensé que el error se debía a algun tema de lógica o del servidor, sin embargo, luego supe que este error se debía a que se intentó correr una clase compilada con JDK 1.5 en un ambiente JRE 1.4, el cuál fue el que dió el error. Esto se da por motivo de las nuevas características introducidas en la versión más reciente de Java y que no están presentes en la versión anterior.

Para resolver este error tuve que verificar que versión del compilador se está empleando y cambiarla por la más apropiada (en mi caso la tuve que bajar a 1.4).

Acá les dejo un enlace sobre este tema. Resolving the “Unsupported major.minor version 49.0″ Error