Archiva 1.2.1 sobre JBoss AS 4.0.5 en Windows 64

El primer paso es descargar JBoss 4.05 de la web de descargas de la comunidad de JBoss. Se descomprime en C:\ y se descarga el utilitario para instalarlo como servicio. Esta parte es muy simple y se explica en la siguiente url: http://www.jboss.org/community/wiki/JBossNativeWindows.

Una vez hecho esto, procedemos a montar Apache Archiva. Como vamos a usar de base de datos Derby, debemos copiar derby-10.1.3.1.jar y derbytools-10.1.3.1.jar en la carpeta server\default\lib.
Extraemos archiva-1.2.1.war en la carpeta server\default\deploy\archiva.war.

Creamos el archivo server\default\deploy\derby-ds.xml, con el siguiente contenido:

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
  <local-tx-datasource>
     <jndi-name>users2</jndi-name>
     <connection-url>jdbc:derby:database/archiva;create=true</connection-url>
     <driver-class>org.apache.derby.jdbc.EmbeddedDriver</driver-class>
     <user-name>sa</user-name>
     <password></password>
     <min-pool-size>5</min-pool-size>
     <max-pool-size>20</max-pool-size>
     <idle-timeout-minutes>5</idle-timeout-minutes>
     <track-statements/>
  </local-tx-datasource>
  <local-tx-datasource>
     <jndi-name>archiva</jndi-name>
     <connection-url>jdbc:derby:database/archiva;create=true</connection-url>
     <driver-class>org.apache.derby.jdbc.EmbeddedDriver</driver-class>
     <user-name>sa</user-name>
     <password></password>
     <min-pool-size>5</min-pool-size>
     <max-pool-size>20</max-pool-size>
     <idle-timeout-minutes>5</idle-timeout-minutes>
     <track-statements/>
  </local-tx-datasource>
</datasources>

Necesitamos crear también el server\default\deploy\archiva.war\META-INF\context.xml:

<Context path="/archiva" docBase="/">
  <Resource name="jdbc/users" auth="Container" 
            type="javax.sql.DataSource" username="sa" password=""  
            driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
            url="jdbc:derby:database/users;create=true" />
  <Resource name="jdbc/archiva" auth="Container"
            type="javax.sql.DataSource" username="sa" password=""
            driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
            url="jdbc:derby:database/archiva;create=true" />
  <Resource name="mail/Session" auth="Container"
            type="javax.mail.Session"
            mail.smtp.host="localhost"/>
</Context> 

En server\default\deploy\archiva.war\WEB-INF\classes\application.properties tenemos que añadir appserver.home y appserver.base:

user.agent=Apache Archiva/1.2.1
appserver.base=
appserver.home=

Y por último, añadimos el server\default\deploy\archiva.war\WEB-INF\jboss-web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
 <resource-ref>
   <res-ref-name>jdbc/users</res-ref-name>
   <jndi-name>java:/users2</jndi-name>
 </resource-ref>
 <resource-ref>
   <res-ref-name>jdbc/archiva</res-ref-name>
   <jndi-name>java:/archiva</jndi-name>
 </resource-ref>
 <resource-ref>
   <res-ref-name>mail/Session</res-ref-name>
   <jndi-name>java:/Mail</jndi-name>
 </resource-ref> 
</jboss-web>

Profit!

Acelerando Maven2

El primer paso, si no lo has hecho ya, es instalar Maven2. Desde que compré mi nuevo portátil no he vuelto a usar Maven, por lo que describiré muy brevemente los pasos que he seguido.

Descarga Maven 2.0.9 y extraelo en tu directorio de archivos de programa (en Windows, lo extraigo en C:\Program Files). Añade una nueva variable de entorno llamada MVN con el valor C:\Program Files\apache-maven-2.0.9\bin, y edita el Path para referenciarla (añade ;%MVN% al final de tu Path). Abre una nueva consola y ejecuta mvn -v. Si devuelve la versión instalada de Maven2, todo marcha bien 🙂

Maven2 automáticamente descarga todas las dependencias que se necesiten para compilar una aplicación (vienen definidas en el POM). Por tanto, para acelerar estos procesos, es interesante añadir un mirror cercano geográficamente. En mi caso, el CICA es mirror de Apache, por lo que está en mi propia ciudad 🙂

Para más información, consulta Maven Guide Mirror Settings.

PD: El asunto de esta entrada era sólo un paso necesario para una futura entrada, y estaba escrito en inglés, pero al final era esfuerzo inútil (ya veréis por que motivo en próximos capítulos). He preferido publicar este minipost antes que borrar una parte del esbozo del siguiente.

Nueva lista de correo sobre ecosistemas software

Leo en lo de Manuel Recena:

En esta ocasión escrito para comunicar que se ha creado una nueva lista de correo (http://groups.google.com/group/ecosistemas-software ) para tratar temas relacionados con ecosistemas software basados en herramientas con licencias de código abierto. La lista de correo acaba de ser creada y esperamos que sea bien aceptada por la comunidad de desarrolladores.

Particularmente mi aportación estará centrada en las herramientas con la que tengo experiencia, sin embargo, tengo mucho interés por conocer otras configuraciones de ecosistemas software. Esas herramientas son Maven, Archiva y Continuum, todas ellas de Apache Foundation.

Yo ya estoy apuntado… ¿Lo harás tú?

Revisiones de código

Una de las cosas que siempre me han gustado es leer código de otros. Se aprende mucho, y es divertido intentar buscar optimizaciones, o bugs. En ArgoUML he estado haciendo esto alguna vez con FindBugs, y leo con calma todos los diffs enviados a la lista de commits.

Hoy Rodrigo Corral hacía un llamamiento en su blog, preguntándose cómo se podrían calcular las horas que han pasado desde principio de año hasta una fecha dada.

También habló Ricardo sobre revisiones de código en Subversion hace algún tiempo, y aún espero con ilusión que algún caminante deje un comentario a ese post sobre alguna herramienta que yo desconozca.

Hoy alguien ha mandado unas simples optimizaciones para la clase Int32 a la lista de desarrollo de Mono, un proyecto muy maduro, por lo que me sorprende que esta optimización no se haya realizado hace tiempo.

Por lo que se me ocurre una pregunta… ¿Cuántos ojos ven tu código?
Da igual la licencia que tenga, que el código esté disponible no significa que alguien lo lea.
¿Qué soluciones usas para las revisiones de código? ¿Es el Pair Programming algo realmente factible para un negocio?

Seguridad: El Error Humano

La seguridad en un sistema informático depende de tres factores:

• Procesos.
• Personas.
• Tecnología.

Los problemas de seguridad pueden venir dados por un problema en cualquiera de estos tres factores.

Podemos encontrar fallos en los procesos. Un ejemplo de fallo en los procesos puede ser, lamentablemente, ignorar totalmente la seguridad. La seguridad es una métrica, no una característica, y por tanto en un proceso de ingeniería del software debemos cuantificar la seguridad, como parte de los requisitos no funcionales de la aplicación. Para cuantificar la seguridad, podemos acudir a una metodología conocida como Modelado de Amenazas.

Obviamente, podemos encontrar fallos en la tecnología. Podemos encontrar problemas en los protocolos a utilizar, en el sistema operativo, en el software del sistema, o, lo más común, en el software desarrollado a medida. El software no es perfecto. Para paliar este problema debemos tener las últimas actualizaciones del software que utilicemos.

Y, por último, podemos encontrar fallos en las personas. Es el más común de los problemas. Este factor ha sido, sin duda, uno de los que mayores y mejores chistes ha dado a la informática. Muestra de ello, son los siguientes:

El problema está entre su ordenador y la silla.

Problema en el usuario. Cambie de usuario y pulse continuar.

Pero sin duda, me quedo con la siguiente cita:

Hoy en día la programación es una carrera entre los ingenieros de software, afanándose por construir mejores y más grandes programas a prueba de idiotas, y el Universo, intentando producir mejores y más grandes idiotas. Hasta ahora, el Universo va ganando…

Rick Cook