Í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:
- http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=mavenRelease
- http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=maven
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 hacemosmvn 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:
...
<distributionManagement>
...
<site>
<id>your_project.sf.net</id>
<url>scp://web.sourceforge.net/htdocs</url>
</site>
</distributionManagement>
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:
alex@cell-2:~/tmp/bugzillachanges/trunk/bugzillaRelease$ mvn site:deploy
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Bugzilla Release Maven Mojo
[INFO] task-segment: [site:deploy]
[INFO] ------------------------------------------------------------------------
[INFO] [site:deploy {execution: default-cli}]
scp://web.sourceforge.net/home/groups/b/bu/bugzillachanges/htdocs/maven-site/bugzillaRelease - Session: Opened
Executing command: mkdir -p /home/groups/b/bu/bugzillachanges/htdocs/maven-site/bugzillaRelease/.
Executing command: mkdir -p /home/groups/b/bu/bugzillachanges/htdocs/maven-site/bugzillaRelease/.
Executing command: scp -t "/home/groups/b/bu/bugzillachanges/htdocs/maven-site/bugzillaRelease/./wagon224966416246538091.zip"
Transfer error: java.io.IOException: SCP terminated with error: 'scp: "/home/groups/b/bu/bugzillachanges/htdocs/maven-site/bugzillaRelease/./wagon224966416246538091.zip": No such file or directory'
Transfer error: org.apache.maven.wagon.TransferFailedException: Error occurred while deploying './wagon224966416246538091.zip' to remote repository: scp://web.sourceforge.net/home/groups/b/bu/bugzillachanges/htdocs/maven-site/bugzillaRelease: SCP terminated with error: 'scp: "/home/groups/b/bu/bugzillachanges/htdocs/maven-site/bugzillaRelease/./wagon224966416246538091.zip": No such file or directory'
scp://web.sourceforge.net/home/groups/b/bu/bugzillachanges/htdocs/maven-site/bugzillaRelease - Session: Disconnecting
scp://web.sourceforge.net/home/groups/b/bu/bugzillachanges/htdocs/maven-site/bugzillaRelease - Session: Disconnected
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error uploading site
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:
...
<distributionManagement>
...
<site>
<id>your_project.sf.net</id>
<url>scp://shell.sourceforge.net/home/groups/y/yo/your_project/htdocs</url>
</site>
</distributionManagement>
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»
