Cómo hacer deploy del site de Maven en SourceForge

0
9137

Índice de contenidos

1. Introducción
2. Entorno
3.El camino obvio, el camino equivocado
4.El camino menos obvio, el camino correcto
5.Conclusiones
6.Sobre el autor

1. Introducción

Este tutorial requiere de conocimientos previos de Maven. Es necesario que el lector sepa como hacer una release, y generar el site, y hacer deploy del site de un proyecto gestionado con Maven. Algunos tutoriales relacionados con esto:

También requiere que el lector conozca los mecanismos que utiliza SourceForge para gestionar los proyectos.

Veamos de todas formas algunas definiciones para refrescar ideas:

  • Maven (http://maven.apache.org/) sistema de gestión de proyectos Java, que permite: compilar, empaquetar, generar documentación, …
  • Site: El site de Maven son un conjunto de ficheros html que Maven genera automáticamente a partir de ficheros apt (ficheros de texto tipo wiki que se encuentran entre los fuentes de nuestro proyecto). Estos html contendrán documentación sobre el
    proyecto.
  • Hacer deploy del site: Cuando hacemos mvn site:site, Maven genera los html. Cuando hacemos mvn site:deploy, Maven se encarga de copiar esos html en una ruta
    que hemos especificado en la configuración. Normalmente se tratará de un directorio en una máquina remota, donde este directorio estará publicado a través de un servidor web, como el Apache, de forma que las páginas html sean accesibles desde cualquier
    navegador.
  • SourceForge: (https://sourceforge.net/): Comunidad donde podemos encontrar proyectos Free-Software u Open-Software. En esta comunidad, cualquier de nosotros puede crear un proyecto. SourceForge nos proporciona espacio web, repositorio de
    código, espacio para subir ficheros, wiki, sistema de gestión de incidencias, y muchísimo más.

En este tutorial vamos a ver como conseguir hacer un deploy del site de un proyecto de Maven en el espacio web que nos proporciona SourceForge.


2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 17′ (2.93 GHz Intel Core 2 Duo, 4GB DDR3 SDRAM, 128GB Solid State Drive).
  • NVIDIA GeForce 9400M + 9600M GT with 512MB
  • Sistema Operativo: Mac OS X Leopard 10.5.6


3. El camino obvio, el camino equivocado

Cuando tenemos un proyecto en SourceForge, tenemos varias URL, para acceder a sus recursos. Normalmente para copiar, o en general gestionar, los ficheros que forman parte del sitio web de nuestro proyecto, usamos la URL:

<username>,<projectname>@web.sourceforge.net

Donde <username> es nuestro nombre de usuario en SourceForge, y <projectname> es el nombre de nuestro proyecto en SourceForge. Estos dos valores separados por una coma «,» forman el nombre de usuario para autenticarnos en el servidor web.sourceforge.net

Según esto, si queremos que Maven haga el deploy del site en nuestro espacio web de SourceForge, parecería obvio que usáramos esta URL. La podríamos configurar de la siguiente manera en nuestro pom.xml:

Así le estamos diciendo a Maven que cuando haga el deploy del site, los ficheros html generados, los copie dentro del directorio htdocs.

Pues bien, esto sólo tiene un pequeòo inconveniente, y es que no funciona. Lo más probable es que nos de un error del estilo:

En el mensaje de error se puede ver como, en la línea 12, se queja porque parece que no encuentra un zip. ¿Qué esta ocurriendo? Wagon es el plugin que usa Maven para hacer todo el trasiego/copia de información. Maven va a intentar hacer un zip, copiarlo, descomprimirlo, cambiarle los permisos, … y muchos de estos comandos van a fallar si los
intentamos hacer a través de la URL web.sourceforge.net

Veamos en el siguiente punto la solución.


4. El camino menos obvio, el camino correcto

Para solucionar estos problemas tenemos que usar otra URL que también nos proporciona SourceForge:

shell.sourceforge.net

De esta forma configuraremos nuestro pom.xml:

Nótese como estamos indicando todo el path hasta el directorio htdocs. Este path dependerá del nombre nuestro proyecto.

Atención!!! Ahora para que funcione correctamente el mvn site:deploy, antes tenemos que ejecutar:

ssh -t <username>,<projectname>@shell.sf.net create

Esto es porque la interfaz «shell» sólo está disponible durante un determinado periodo de tiempo (unas dos horas), y luego se cierra automáticamente. Es decir, es como si se tratara de una conexión, y con el comando anterior lo que estamos haciendo es crear
una nueva conexión. Si ya tuviéramos una sesión creada no hace falta crear otra, simplemente hay que asegurarse que tenemos una sesión «shell» creada. Para comprobar si ya tenemos creada una sesión, bastaría con ejecutar línea, pero sin el comando «create».
Si no se conecta y nos da un error es que todavía no hay sesión creada.

5. Conclusiones

Lo obvio no es siempre lo correcto, pero no hay nada que se nos resista con un poco de investigación. Para eso estamos en Autentia (www.autentia.com) para pegarnos con estas cosas y conseguir que vosotros viváis más tranquilos.

6. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»

http://www.autentia.com

 

Dejar respuesta

Please enter your comment!
Please enter your name here