Archivo de la categoría: DEBUN_Tools

Multi-Release JARs

En los últimos años Java ha estado evolucionando muy rápido con el nuevo ciclo de distribución en el que se liberan 2 nuevas versiones por año.

Con la nueva versión 17 Long Time Support (LTS) de la JDK y la versión 18 a la vuelta de la esquina, muchos desarrollos aún están asimilando la anterior versión LTS, la JDK 11.

Se hace patente el hecho que los desarrollos de aplicaciones Java no pueden seguir el ritmo en el que van apareciendo las nuevas características del lenguaje y por eso muchas de ellas tardan en ser de uso general. Una de las consecuencias de este hecho es que los desarrolladores de librerías y frameworks están forzados a esperar hasta que la base de aplicaciones a los que dan soporte se adapta para seguir siendo compatibles con ellas.

Desde la aparición de Java 9 han aparecido mecanismos para paliar este hecho, posibilitando la construcción de artefactos compatibles con múltiples versiones de JDK: Uno de ellos son los Multi-Release JARs (MRJAR), que hace posible integrar en un mismo componente (fichero JAR) diversas versiones de código compatibles con múltiples versiones de JDK.

En este artículo se explica el funcionamiento de los MRJAR así como su integración en un proyecto construido mediante Maven.

Seguir leyendo Multi-Release JARs

Uso de toolchains Maven

Un toolchain en Maven es un mecanismo que permite a los plugins que se ejecutan durante las diferentes fases de construcción de un artefacto acceder a un conjunto de herramientas predefinido de forma general. De esta forma se evita que cada uno de ellos deba definir la composición y ubicación de este conjunto de herramientas y se homogeniza para que en todos los casos sea la misma. Habitualmente este mecanismo se utiliza para proporcionar la especificación de la jdk que será utilizada en el proceso de construcción en los casos que se deba utilizar una implementación diferente a utilizada para ejecutar el propio Maven, pero existe la posibilidad de construir toolchains personalizadas. El uso de las diferentes tipologías de toolchains debe estar soportado por los plugins utilizados. Afortunadamente, plugins básicos como maven-compiler-plugin, maven-javadoc-plugin, maven-surefire-plugin, entre otros, están diseñados para dar soporte a toolchains de tipo jdk, lo que permite definir procesos de construcción para diferentes implementaciones de jdk sin problema.

En este artículo se explicarán los pasos necesarios para definir una toolchain en la instalación local de Maven y de como utilizarla en la construcción de un artefacto.

Seguir leyendo Uso de toolchains Maven

Inclusión de recursos zip como dependencias Maven

Maven es una herramienta altamente utilizada en el ecosistema Java para gestionar los módulos y librerías que componen una aplicación, ya sea directamente a través del própio Maven o de otras herramientas, como Gradle, SBT, Ivy, etc., que utilizan los repositorios de este para obtener dichos recursos. A parte de artefactos de tipo jar, war o definiciones pom, Maven también permite gestionar empaquetados de tipo zip en los repositorios. Esto permite gestionar dependencias a recursos estáticos comunes en varios proyectos Maven sin necesidad de duplicarlos en cada uno de ellos, facilitando así su mantenimiento y actualización. En este artículo se muestra de forma genérica como incluir recursos comunes en un proyecto Maven a través de una dependencia y un caso concreto de como aprovechar esto para gestionar paquetes npm de forma local sin tener que hacer uso de un repositorio npm remotoé

Seguir leyendo Inclusión de recursos zip como dependencias Maven

Sdkman – The Software Development Kit Manager

SDKMAN! es una herramienta para manejar versiones paralelas de múltiples Kits de Desarrollo de Software en la mayoría de los sistemas basados en Unix. En este post, aunque originalmente está pensando para sistemas Unix veremos su utilización mediante Java en su version 11 en entornos Windows, concretamente con Windows 10.

Proporciona una conveniente Interfaz de Línea de Comando (CLI) y API para instalar, cambiar, eliminar y listar candidatos.

Anteriormente conocido como GVM el Groovy enVironment Manager, fue inspirado por las muy útiles herramientas RVM y rbenv, utilizadas en general por la comunidad Ruby.

Para poder ser utilizando en entornos Windows es neceasario realizar una refacorización del código fuente del script bash original.

Existe una sección (install) en la propia página web dónde se indican los pasos a seguir para su instalación y utilización en entornos Windows.

Para mostrar su uso en Windows 10 se utiliza el Shell de Git Bash mediante el uso de este script get_sdkman_io (ya preparado para funcionar en entornos Windows).

Seguir leyendo Sdkman – The Software Development Kit Manager

Creación de un Fat Jar con Apache Maven

Hace un tiempo publiqué un post en este mismo blog en el que se explicaba cómo se construir un Fat Jar con Apache Ant para empaquetar toda una aplicación, dependencias incluidas, dentro de un mismo fichero jar. El procedimiento para ello se basa en extraer los ficheros .class compilados que se encuentran dentro de los jars de las dependencias incluirlo dentro del jar principal de la aplicación. En caso de utilizar Maven cómo herramienta de construcción en lugar de Ant, esta acción se puede realizar utilizando el plugin Shade. Para ello será necesario incluir su definición dentro del fichero pom.xml del proyecto y asociar la ejecución de su único goal "shade" a la ejecución de la fase de empaquetado "package":

Seguir leyendo Creación de un Fat Jar con Apache Maven

Creación de un Fat Jar con Apache ANT

Normalmente para construir el distribuible de una aplicación Java se empaqueta el código principal de esta dentro de un fichero jar ejecutable, esto es, que contiene dentro de su fichero de definición MANIFEST.MF una entrada que especifica qué clase contiene el metodo main() y junto a este se crea una carpeta que contenga todas las dependéncias que este (habitualmente se llama a esta carpeta lib).

Seguir leyendo Creación de un Fat Jar con Apache ANT

Ejecución de Maven des de consola de comandos MS-DOS

Caso de Ejemplo: Se dispone de un proyecto multi-módulo del que se desean desplegar varios de sus módulos.
Se dispone de Maven en su versión 2.2 y de un servidor Weblogic 9.2 Mp4 para los módulos J2EE de las aplicaciones.
Para automatizar los despliegues de dichos módulos sin necesidad de acceder ni recorrer el árbol de directorios mediante la consola de comandos DOS del Windows 7 se ha creado el siguiente script.

Este script ejecuta los despliegues de cada  uno de los módulos que forman el proyecto J2EE en la carpeta establecida como ruta de despliegue para el servidor Weblogic en el fichero de configuración de Maven.

Además, informa de los nombres de los módulos y de los tiempos en que se ejecuta cada uno de los despliegues y lo almacena todo en un fichero llamado resultado.txt, que puede consultarse con posterioridad.

Una vez realizadas todas las tareas se publica en el fichero un mensaje de finalización de éxito:

echo =================================================
echo TODOS LOS MODULOS HA SIDO DESPLEGADOS CON EXITO  
echo =================================================

Detalle: A continuación se detalla una sección del código fuente del fichero .bat explicando un poco su funcionalidad.

La sección más importante del script es esta sección:

  • ECHO __________>>resultado.txt.
  • echo Modulo ST >>resultado.txt.  Título  del módulo.
  • time /t>>resultado.txt. Se indica el inicio del tiempo de despliegue.
  • ECHO __________>>resultado.txt. 
  • call mvn package war:exploded -f<Ruta_ubicación_fichero_pom>pomITT.xml>>resultado.txt. Se llama al maven  mediante la instrucción call de DOS para ejecutar el despliegue del módulo actual.
  • if not %ERRORLEVEL% == 0 exit /b. En caso de error salimos de la consola de comandos.
  • time /t>>resultado.txt. Se indica el final del tiempo de despliegue y se escribe la salida de pantalla al fichero de texto de resultado.txt.

Se sobreentiende que el fichero POM.xml de cada uno de los módulos o proyectos J2EE ya incluye en su  sección de despliegue la ruta correcta para el servidor Weblogic (En todo caso debe indicarse cuál es la ruta correcta para realizar los despliegues pertinentes).

Actualización del 20/01/2015

En lugar de escribir directamente la ruta de cada uno de los ficheros se utiliza el paso de parámetros en el script. En lugar de utilizar esta línea de código:

call mvn package war:exploded -f<Ruta_ubicación_fichero_pom>pomITT.xml>>resultado.txt 

se modifica esta llamada por esta otra línea de código:

call mvn install -f%1<nombre_del proyecto>pom.xml>>resultado.txt

El %1 permite recuperar la ruta en la que se encuentran los proyectos en desarrollo accediendo al fichero POM pasando dicha ruta como parámetro al script.  Puede utilizarse cualquier ruta o directorio siempre que el directorio disponga de fichero pom.xml con una configuración Maven, sino el script dará un error.
Este cambio por un lado nos permite ejectuar la llamada de Maven en todos los proyectos indistintamente de su ubicación dentro del sistema de archivos dado que la carpeta contenedora siempre se pasa por parámetro.
La configuración de Maven (dentro de la etiqueta <build><plugin>) dentro del fichero POM es la siguiente:
           <plugin>
<groupId>
org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webXml>src/main/webapp/WEB-INF/web.xml</webXml>
<attachClasses>true</attachClasses>
<classesClassifier>classes</classesClassifier>
<encoding>ISO-8859-1</encoding>
<webappDirectory>C:/Weblogic_Despliegues/${project.artifactId}</webappDirectory>
</configuration>
</plugin>

El script de ejecución puede encontrarse en este enlace.

Para un mayor detalle sobre el plugin de maven-war-plugin se puede encontrar información detallada en este enlace.

Building a Project in Maven

mvn package   –  package is a phase ( ordered sequence of steps = phases ).

Default life cycle contains next building phases –> The Lifecycle Reference:

  • validate validate the project is correct and all necessary information is available

 

  • compile compile the source code of the project

 

  • test test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed

 

  • package take the compiled code and package it in its distributable format, such as a JAR.

 

  • integration-test – process and deploy the package if necessary into an environment where integration tests can be run

 

  • verify run any checks to verify the package is valid and meets quality criteria

 

  • install install the package into the local repository, for use as a dependency in other projects locally

 

  • deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

=========================================================================

Guía Rápida Maven

Descripciones de los términos más conocidos

  • ArtifactId: Identificador de un proyecto en Maven. Dentro del repositorio es la carpeta última contenedora de los ficheros de la librería
  • groupId: Grupo identificador asociado al proyecto. Un proyecto debe pertenecer obligatoriamente a un grupo
  • archetpe:create Comando para crear un proyecto Maven vacío
mvn archetype:generate 
    -DgroupId=com.mycompany.app 
    -DartifactId=my-app 
    -DarchetypeArtifactId=maven-archetype-quickstart 
    -DinteractiveMode=false
  • package: Permite generar un jar, war o web desplegada (opción exploded). Está formado por la versión del proyecto y por el indicador de la construcción.

Ejemplo:    1.0         –    SNAPSHOT
(versión)      (indicador de proceso de construcción)

NOTA: Sise utiliza la agrupación de los 2 se considera que es la VERSIÓN la que se debe indicar en la mayoria de referencias de Poms dependientes o jerarquizados.

 

Para obtener la versión de Maven instalada en el sistema en Windows se debe ejecutar el siguiente comando:

mvn -version

Aparecerá por pantalla la versión de Maven instalada en el sistema.

Dentro de Maven se crea un directorio siguiendo el esquema definido por el standard project structure de Maven. Se compone de los siguientes elementos:

my-app
|
|-- pom.xml
|
|-- src
     |-- main
     |   |-- java
     |       |-- com
     |           |-- mycompany
     |               |-- app
     |                   |-- App.java
     |-- test
         |-- java
             |-- com
                 |-- mycompany
                     |-- app
                         |-- AppTest.java

Dónde src/main/java contiene el código fuente del proyecto, src/test/java contiene el código fuente de test y el fichero pom.xml es el Project Object Model oPOM.

El POM es una representación XML de un proyecto Maven contenido en un archivo denominado pom.xml.  Este fichero puede contener información de la configuración del proyecto, de las personas involucradas y del rol rol que ejercen, del sistema de control de incidencias, la organización, licencias, URL dónde reside el proyecto, dependencias del proyecto y todas las piezas que dan sentido al código. En el mundo de Maven, un proyecto no necesita contener ningún tipo de código, simplemente un pom.xml.