eXtreme Programming según Dilbert

Empaquetar una aplicación de consola con Maven

Veremos cómo configurar el POM de un proyecto de una aplicación de consola para obtener un archivo zip conteniendo la aplicación y todas sus dependencias (JARs), y un directorio con los archivos de configuración de la aplicación.

Llamaremos a nuestro proyecto console-poc, que va a ser también el artifactId del POM.

Estructura de directorios

Vamos a agregar algunos directorios a la estructura de directorios de nuestro proyecto que es la standard de Maven.

Agregaremos src/main/bin, para contener los scripts de ejecución de la aplicación y src/main/config para contener los archivos de configuración:

src/
|-- main
|   |-- bin
|   |   |-- run.cmd
|   |   `-- run.sh
|   |-- config
|   |   |-- application.properties
|   |   |-- applicationContext.xml
|   |   `-- log4j.xml
|   `-- java
|       `-- com
...

JAR plugin: agregar el directorio src/main/config al Manifest

Configuramos el plugin de JAR en el POM para que agregue el directorio src/main/config al classpath definido en el Manifest de la aplicación.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<!-- esto hace que al crear el jar se nombre console-poc.jar en vez de console-poc-1.0.0.jar si la versión del artifact es 1.0.0 -->
<finalName>${artifactId}</finalName>
<archive>
<manifest>
<!-- agregar todos los .jar de las dependencias en el classpath del Manifest -->
<addClasspath>true</addClasspath>
<!-- vamos a agregar antes del nombre de cada .jar en el classpath del Manifest el prefijo lib/ -->
<!-- porque luego al construir el assembly copiaremos los .jar de las dependencias al directorio lib/-->
<classpathPrefix>lib/</classpathPrefix>
<!-- la clase que se ejecuta cuando se ejecute "java -jar console-poc.jar" -->
<mainClass>ar.com.kamikazesoftware.poc.console.App</mainClass>
</manifest>
<manifestEntries>
<!-- además de los nombres de las dependencias, agregar el directorio config al classpath del Manifest -->
<Class-Path>config/</Class-Path>
</manifestEntries>
</archive>
</configuration>
</plugin>

Assembly Plugin

Configuramos el plugin de Assembly para usar un descriptor llamado distribution.xml que el plugin tomará del directorio src/main/assembly:

<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration> 
<descriptors>
<!-- el descriptor contiene la información para armar el assembly -->
<descriptor>src/main/assembly/distribution.xml</descriptor>
</descriptors>
</configuration>
<executions>
<!-- ejecutar el goal 'single' del plugin de assembly al ejecutar mvn package -->
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>    
</plugin>

En execution se define que se ejecute el goal 'single' del plugin de assembly cuando se ejecute 'mvn package' desde el directorio de nuestro proyecto, es decir que construya el assembly cuando se ejecute 'mvn package'.

A continuación el descriptor distribution.xml comentado:

<assembly>
<id>distribution</id>

<!-- el formato de salida es archivo .zip -->
<formats>
<format>zip</format>
</formats>

<!-- incluir todas las dependencias runtime en el directorio lib del archivo .zip de salida-->
<dependencySets>
<dependencySet>
<outputDirectory>/lib</outputDirectory>
<useProjectArtifact>false</useProjectArtifact>
</dependencySet>
</dependencySets>

<fileSets>
<!-- incluir el jar de la aplicación en el directorio base del archivo .zip -->
<fileSet>
<directory>target</directory>
<outputDirectory></outputDirectory>
<includes>
<include>*.jar</include>
</includes>
</fileSet>

<!-- copiar los scripts al directorio base del archivo .zip -->
<fileSet>
<directory>src/main/bin</directory>
<outputDirectory></outputDirectory>
<includes>
<include>run.cmd</include>
<include>run.sh</include>
</includes>
</fileSet>

<!-- copiar los archivos de configuración al directorio config del archivo .zip -->
<fileSet>
<directory>src/main/config</directory>
<outputDirectory>/config</outputDirectory>
<includes>
<include>**/**</include>
</includes>
</fileSet>
</fileSets>
</assembly>

Script para ejecutar la aplicación desde linea de comandos

El script run.sh (y run.cmd la versión Windows), contiene la siguiente linea que ejecuta la máquina virtual de java parametrizada para ejecutar la aplicación:

java -jar console-poc.jar

Ensamblado

Con esta configuración ejecutamos

mvn clean package

en una terminal, parados en el directorio de nuestro proyecto, y en el directorio target se creará un archivo console-poc-0.0.1-SNAPSHOT.zip con el assembly.

Ver también

En una futura ocasión hablaremos de otro plugin para armar paquetes, el
Appassembler plugin que entre otras cosas arma el script de ejecución automaticamente.

HSQL en modo server en JBoss AS

El propósito de este artículo es mostrar cómo habilitar la instancia de HSQL que corre en JBoss AS para que sea una instancia en modo server. El modo server de HSQL permite acceder a la base a través de clientes JDBC, lo cual puede ser útil para llevar a cabo acciones sobre la base de datos y sus tablas con una herramienta como Squirrel.

Convenciones

• $JBOSS_HOME es el directorio donde está instalado JBoss.
• $JBOSS_HOST es la dirección ip o host donde está instalado JBoss
• La configuración de JBoss que vamos a modificar es la default.

Habilitar Binding

En $JBOSS_HOME/server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml, descomentar:

<bean class="org.jboss.services.binding.ServiceBindingMetadata">
 <property name="serviceName">jboss:service=Hypersonic</property>
 <property name="port">1701</property>
 <property name="description">TCP/IP socket for remote connection to Hypersonic database</property>
</bean>

Data Source

Modificar el archivo $JBOSS_HOME/server/default/deploy/hsqldb-ds.xml para ejecutar HSQL en modo server. El archivo que viene con JBoss tiene la configuración para este fin comentada, sólo hay que descomentar lo que se necesite y comentar lo que se deja de usar. Aqui muestro cómo quedaría:

<?xml version="1.0" encoding="UTF-8"?>

<!-- The Hypersonic embedded database JCA connection factory config -->

<!-- See http://www.jboss.org/community/wiki/Multiple1PC for information about local-tx-datasource -->
<!-- $Id: hsqldb-ds.xml 97536 2009-12-08 14:05:07Z jesper.pedersen $ -->

<datasources>
<local-tx-datasource>
<!-- The jndi name of the DataSource, it is prefixed with java:/ -->
<!-- Datasources are not available outside the virtual machine -->
<jndi-name>DefaultDS</jndi-name>

<!-- For server mode db, allowing other processes to use hsqldb over tcp.
This requires the org.jboss.jdbc.HypersonicDatabase mbean. -->
<connection-url>jdbc:hsqldb:hsql://${jboss.bind.address}:1701</connection-url>

<!-- The driver class -->
<driver-class>org.hsqldb.jdbcDriver</driver-class>

<!-- The login and password -->
<user-name>sa</user-name>
<password></password>

<!--example of how to specify class that determines if exception means connection should be destroyed-->
<!--exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.DummyExceptionSorter</exception-sorter-class-name-->

<!-- this will be run before a managed connection is removed from the pool for use by a client-->
<!--<check-valid-connection-sql>select * from something</check-valid-connection-sql> -->

<!-- The minimum connections in a pool/sub-pool. Pools are lazily constructed on first use -->
<min-pool-size>5</min-pool-size>

<!-- The maximum connections in a pool/sub-pool -->
<max-pool-size>20</max-pool-size>

<!-- The time before an unused connection is destroyed -->
<!-- NOTE: This is the check period. It will be destroyed somewhere between 1x and 2x this timeout after last use -->
<!-- TEMPORARY FIX! - Disable idle connection removal, HSQLDB has a problem with not reaping threads on closed connections -->
<idle-timeout-minutes>0</idle-timeout-minutes>

<!-- sql to call when connection is created
<new-connection-sql>some arbitrary sql</new-connection-sql>
-->

<!-- sql to call on an existing pooled connection when it is obtained from pool 
<check-valid-connection-sql>some arbitrary sql</check-valid-connection-sql>
-->

<!-- example of how to specify a class that determines a connection is valid before it is handed out from the pool
<valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.DummyValidConnectionChecker</valid-connection-checker-class-name>
-->

<!-- Whether to check all statements are closed when the connection is returned to the pool,
this is a debugging feature that should be turned off in production -->
<track-statements/>

<!-- Use the getConnection(user, pw) for logins
<application-managed-security/>
-->

<!-- Use the security domain defined in conf/login-config.xml -->
<security-domain>HsqlDbRealm</security-domain>

<!-- Use the security domain defined in conf/login-config.xml or the
getConnection(user, pw) for logins. The security domain takes precedence.
<security-domain-and-application>HsqlDbRealm</security-domain-and-application>
-->

<!-- HSQL DB benefits from prepared statement caching -->
<prepared-statement-cache-size>32</prepared-statement-cache-size>

<!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
<metadata>
<type-mapping>Hypersonic SQL</type-mapping>
</metadata>

<!-- Uncomment when using hsqldb in server mode -->
<depends>jboss:service=Hypersonic</depends>
</local-tx-datasource>

<!-- Uncomment if you want hsqldb accessed over tcp (server mode) -->
<mbean code="org.jboss.jdbc.HypersonicDatabase" name="jboss:service=Hypersonic">
<attribute name="Port">        
<value-factory bean="ServiceBindingManager" method="getIntBinding"  parameter="jboss:service=Hypersonic"/>
</attribute>
<attribute name="BindAddress">        
<value-factory bean="ServiceBindingManager" method="getStringBinding" parameter="jboss:service=Hypersonic"/>
</attribute>     
<attribute name="Silent">true</attribute>
<attribute name="Database">default</attribute>
<attribute name="Trace">false</attribute>
<attribute name="No_system_exit">true</attribute>
</mbean>
</datasources>

Cliente

Luego se puede acceder con un cliente configurándolo de la siguiente forma:

Driver Class: org.hsqldb.jdbcDriver (para usar esta clase incluír en el classpath del cliente $JBOSS_HOME/common/lib/hsqldb.jar)
URL: jdbc:hsqldb:hsql://$JBOSS_HOST:1701 (si JBoss estuviera instalado localmente entonces quedaría jdbc:hsqldb:hsql://127.0.0.1:1701)
Username: sa
Password: