Tutorial desarrollado por
Consultor tecnológico de desarrollo de proyectos informáticos. Co-autor del libro "Actualización y mantenimiento del PC (Edición de 2008)" publicado por Anaya Multimedia
Ingeniero Técnico en Informática de Sistemas e Ingeniero en Informática (premio al mejor expediente de su promoción)
Puedes encontrarme en Autentia
Somos expertos en Java/J2EE
Catálogo de servicios de Autentia
Descargar en versión comic (17 MB)
AdictosAlTrabajo.com es el Web de difusión de conocimiento de Autentia.
Descargar este documento en formato PDF: archiva.pdf
Fecha de creación del tutorial: 2008-09-19
Archiva: Gestión de repositorios maven (I).
- 1. Introducción
- 2. Instalación
- 3. Configuración
-
- 3.1 Search -> Find.
- 3.2 Search -> Find Artifact.
- 3.3 Search -> Browse.
- 3.4 Manage -> Reports.
- 3.5 Manage -> User Management.
- 3.6 Manage -> Appearance.
- 3.7 Manage -> Upload Artifact.
- 3.8 Administration -> Repository Groups.
- 3.9 Administration -> Repositories.
- 3.10 Administration -> Proxy Connectors.
- 3.11 Administration -> Legacy Support.
- 3.12 Administration -> Network proxies.
- 3.13 Administration -> Repository Scanning.
- 3.14 Administration -> Database.
- 4. RSS
- 5. Conclusión
1. Introducción
Archiva (http://maven.apache.org/archiva) pertenece al conjunto de proyectos desarrollados por el equipo de Jakarta Maven, como Continuum, SCM, Wagon, JXR, Doxia ... Básicamente es una herramienta de gestión de repositorios maven. Entre las funcionalidades que podemos destacar y que veremos más adelante en el tutorial, podemos citar: gestión de control de acceso a los repositorios definidos, cacheo de artefactos configurando proxys a repositorios remotos y gestión y mantenimiento de repositorios maven 1.x y 2.x (indexación, búsquedas, informes ...).
2. Instalación
El equipo de maven proporciona dos formas de instalar Archiva. Como una aplicación standalone o por medio de una aplicación web (WAR) desplegada en un servidor de aplicaciones Tomcat 5.5 o 6.0.x.
En este tutorial sólo veremos la primera, así que manos a la obra. Primero, descargamos de http://apache.rediris.es/archiva/binaries/apache-archiva-1.1.1-bin.tar.gz la aplicación. Segundo, configuramos el entorno para empezar su instalación siguiendo los siguientes pasos:
- Creamos un usuario y grupo llamados maven.
- su -c "groupadd maven"
- su -c "useradd -g maven maven"
- su -c "passwd maven"
- Creamos un directorio donde situaremos la aplicación standalone. En nuestro caso /opt/maven/archiva, cuyo propietario sera el usuario maven y grupo maven.
- su -c "mkdir /opt/maven"
- chown -R maven:maven /opt/maven
- su -c "su - maven"
- cd /opt/maven
- mkdir archiva
- cd archiva
- tar -xvf apache-archiva-1.1.1-bin.tar.gz
- mkdir repositories
- Crear un conjunto de scripts para el arranque y la parada de archiva.
Nota
Para que archiva arranque adecuadamente el entorno de usuario debe tener configurada una jdk igual o superior a 1.5. En nuestro caso configuraremos nuestro entorno con la jdk 1.6.0_03.
- cd /opt/maven/apache-archiva-1.1.1/bin
- Creamos un script de arranque llamado start.sh que contiene lo siguiente.
JAVA_HOME=/opt/jdk1.6.0_03
ARCHIVA_HOME=/opt/maven/apache-archiva-1.1.1
LOG_ARCHIVA=$ARCHIVA_HOME/logs
export JAVA_HOME
if [ ! -d $LOG_ARCHIVA ]; then
mkdir $LOG_ARCHIVA
fi
if [ -f $ARCHIVA_HOME/bin/archiva ]; then
$ARCHIVA_HOME/bin/archiva start
else
exit 1
fi
Advertencia
Es posible que al ejecutar el comando de arranque, Archiva no se inicie. Esto puede ser debido a que el script "archiva" no reconozca nuestra arquitectura y por tanto no sepa cual es el script que debe lanzar. Para solucionar este problema basta con renombrar el fichero wrapper-arquitectura por wrapper.
- Creamos un script de parada llamado stop.sh
JAVA_HOME=/opt/jdk1.6.0_03
ARCHIVA_HOME=/opt/maven/apache-archiva-1.1.1
LOG_ARCHIVA=$ARCHIVA_HOME/logs
export JAVA_HOME
if [ ! -d $LOG_ARCHIVA ]; then
mkdir $LOG_ARCHIVA
fi
if [ -f $ARCHIVA_HOME/bin/archiva ]; then
$ARCHIVA_HOME/bin/archiva stop
else
exit 1
fi
- Creamos un script de inicialización (/etc/init.d/archiva), que nos permitirá iniciar archiva cuando arranque el sistema.
#
# chkconfig: 345 60 80
# description: Arranca y para el servidor Archiva.
#
# Source function library.
. /etc/rc.d/init.d/functions
ret=0
case $1 in
start)
gprintf "Starting Archiva: "
su -c "/opt/maven/apache-archiva-1.1.1/bin/start.sh" maven &
success "Archiva startup"
ret=$?
echo
;;
stop)
gprintf "Stopping Archiva: "
su -c "/opt/maven/apache-archiva-1.1.1/bin/stop.sh" maven
ret=$?
if [ $ret = 0 ]; then
success "Archiva shutdown"
else
failure "Archiva shutdown"
fi
echo
;;
restart)
$0 stop
sleep 5
$0 start
ret=$?
;;
*)
gprintf "Usage: %s\n" "$(basename $0) {start|stop|restart}"
exit 0
;;
esac
exit $ret
- Ahora utilizamos el comando chkconfig (similar al comando update-rc.d en sistemas basados en debian) para que cree los enlaces necesarios en rcX.d para el arranque y la parada del servicio.
- chkconfig --add archiva
- Si todo ha ido bien, arrancamos archiva.
- cd /etc/init.d/
- ./archiva start
- Y por último, accedemos a la aplicación http://localhost:8080/archiva
3. Configuración
La primera vez que accedemos a Archiva, nos pedirá los datos para crear el usuario administrador de la aplicación:
Figura 1. Creación de usuario administrador.
A continuación, deberemos logarnos en el sistema.
Figura 2. Accediendo a Archiva.
Lo primero que vemos en la parte de la derecha es el menú, dividido en tres grandes bloques:
- Find: opciones para la búsqueda de artefactos subidos a los repositorios definidos en la aplicación.
- Manage: opciones de administración de Archiva como gestión de usuarios, informes y personalización de la aplicación.
- Administration: opciones de gestión/administración de los repositorios.
Figura 3. Menú de navegación.
3.1 Search -> Find
Esta opción permite realizar búsquedas sobre los repositorios definidos. El resultado mostrado serán artefactos que coincidan con el termino buscado o aquellos artefactos que dependan de él. En esta nueva versión podremos buscar artefactos que contengan una determinada clase, método o paquete, sólo tendremos que incluir en la consulta la palabra bytecode (ejemplo: bytecode:getString).
Figura 4. Búsqueda de artefactos.
3.2 Search -> Find Artifact
Esta opción es muy útil en situaciones donde tenemos artefactos anónimos, sin ninguna información que permita conocer a que versión, grupo, etc... pertenece. Con esta funcionalidad podremos localizar si el artefacto en concreto se encuentra subido en algunos de los repositorios gestionados por Archiva. Esto es posible gracias a que indexa todos los recursos, generando ficheros checksum que ayudan a identificar cada artefacto unívocamente en el repositorio.
Archiva utiliza un applet de Java para generar el checksum local del artefacto que posteriormente será utilizado para localizarlo en los repositorios. Para que funcione, debemos aceptar su ejecución la primera vez que accedamos a "Find Artifact".
Figura 5. Applet de generación de checksum.
Posteriormente adjuntamos el fichero que deseamos buscar en el repositorio y pulsamos sobre "Search". Si el artefacto se encuentra en alguno de los repositorios, Archiva nos redirigirá a él. En caso contrario nos mostrará un mensaje indicándonos que el artefacto no se ha encontrado.
Figura 6. Búsqueda de artefactos.
3.3 Find -> Browse
La última opción dentro del bloque "Find" es "Browse". Con esta opción podremos navegar por todos los grupos y artefactos almacenados en los repositorios.
Figura 7. Navegación por artefactos.
Al acceder al detalle de cualquier artefacto, Archiva, muestra cinco pestañas con información relativa a él: Info, Dependencies, Dependency Tree, Used by y Mailing Lists. En todas ellas, en la parte derecha, tenemos la posibilidad de descargar los recursos que se hayan subido del artefacto (source, artefact, pom.xml, etc...).
En la pestaña info, se muestra información genérica como: grupo, artefacto, versión, tipo de empaquetado y el contenido del fichero pom.xml.
Figura 8. Pestaña Info.
En la pestaña Dependencies se muestra la lista de artefactos de los que depende.
Figura 9. Pestaña Dependencies.
En la pestaña Dependency Tree se muestra la misma información que en la anterior, pero presentando la jerarquía en forma de árbol.
Figura 10. Pestaña Dependency Tree.
En la pestaña "Used By" se muestra la lista artefactos subidos al repositorio que dependen de esta versión.
Figura 11. Pestaña Used By.
Y por último la pestaña "Mailing Lists" donde podemos ver la lista de correos de los desarrolladores si estuvieran definidos en el fichero pom.xml.
Figura 12. Pestaña Mailing lists.
3.4 Manage -> Reports
Archiva permite generar informes sobre problemas en los artefactos almacenados en los repositorios. Los informes que podemos generar son muy limitados, únicamente nos permite filtrar por grupo y repositorio y definir el número de errores por pagina. Otro punto débil es la imposibilidad de generar informes en otro formato que no sea html.
Figura 13. Informes.
3.5 Manage -> User Management
Archiva gestiona el acceso a las diferentes funcionalidades y repositorios con roles, distiguiendo dos tipos: roles de administración de Archiva y roles de acceso a repositorios.
3.5.1 Roles de administración de Archiva
Nos encontramos dos roles que podemos asignar al usuario.
- Administrador de usuarios: capaz de crear, editar y asignar permisos a otros usuarios de la aplicación.
- Administrador de la aplicación: se puede ver como el usuario "root" en un sistema linux. Tiene completo control sobre todas las funcionalidades que archiva nos proporciona.
3.5.2 Roles de acceso a repositorios
Tenemos cuatro roles, dos de ellos que si se activan se aplican sobre todos los repositorios y otros dos que son especificos a cada repositorio.
- Global Repository Observer: con este rol el usuario puede acceder en modo lectura a todos los repositorios y utilizar las opciones Browse y Find.
- Global Repository Manager: el usuario puede acceder en modo lectura/escritura y administrar todos los repositorios definidos.
- Repository Observer: mismo comportamiento del rol "Global Repository Observer", pero aplicable exclusivamente a los repositorios seleccionados por el administrador.
- Repository Manager: mismo comportamiento del rol "Global Repository Manager" pero aplicable exclusivamente a los repositorios selecionados por el administrador.
Figura 14. Gestión de usuarios.
3.6 Manage -> Appearance
Con esta opción se permite al administrador realizar una mínima personalización de la aplicación. Podemos incluir en la parte superior derecha una imagen de la organización.
Figura 15. Personalización de aplicación.
3.7 Manage -> Upload Artifact
Esta opción realiza la misma acción que si utilizaramos el goal "deploy:deploy-file" para subir al repositorio un artefacto.
Figura 16. Subida de artefactos.
3.8 Administration -> Repository Groups
Con esta nueva versión se incorpora un nuevo concepto llamado "Repositorio Virtual", que nos permitirá reunir varios repositorios definidos en la opción "Repositories", corportandose como uno único.
Figura 17. Grupo de Repositorios.
3.9 Administration -> Repositories
Con Archiva podemos configurar dos tipos de repositorios: los gestionados por el propio Archiva y los remotos. Los repositorios gestionados son locales, situados en la misma máquina donde tengamos instalado Archiva, pudiendo ser utilizados como repositorios de despligue de artefactos internos a la organización, o como almacén de artefactos de repositorios de terceros utilizando "Proxy Conectors".
Los repositorios remotos, en cambio, son aquellos donde se almacenan artefactos de terceros no gestionados por nuestro servidor y que están situados remotamente. Los Proxies Conectors nos permiten tener en nuestras instalaciones un mirror bajo demanda de repositorios remotos, es decir, almacenamos en nuestro repositorio local todos los artefactos que sean pedidos a los repositorios remotos. Básicamente un Proxy Conector es un enlace entre un repositorio gestionado y un repositorio remoto. Indicar que Archiva nos permite asociar varios repositorios remotos a un único repositorio gestionado.
Archiva tiene configurado por defecto cuatro repositorios; dos remotos que corresponden con el repositorio central de maven y el repositorio del paquete java.net, y otros dos internos. De estos últimos recomendamos la eliminación para situarlos en otros path indenpendientes al servidor de Archiva. Para ello accedemos a la opción "Repositories" y pulsamos sobre el enlace "Delete" de los dos repositorios internos. Tras esta operación nos preguntan si deseamos eliminar la configuración del repositorio y su contenido o únicamente la configuración. En este caso, pulsaremos sobre el botón "Delete Configuration and Contents".
Figura 18. Eliminación de repositorios.
Para añadir nuevo repositorios debemos pulsar sobre el enlace "Add" situado en la sección "Managed Repositories". Se nos pedirán una serie de datos como:
- Identifier: representa el nombre que posteriormente utilizaremos para acceder al repositorio.
- Name: pequeña descripción.
- Directory: ruta donde se depositarán los artefactos.
- Directory Index: ruta donde se deposita información necesaria de indexación de los recursos almacenados en el repositorio y necesario para poder utilizar funcionalidades como Browse, Find, etc...
- Cron: regla donde se define cada cuanto tiempo se lanzarán los procesos de purgación del repositorio.
- Type: con esta opción indicamos la naturaleza del repositorio, es decir, si va albergar artefactos 1.x o 2.x.
- Repository Purge By Days Older Than: número de dias que se mantienen los artefactos Snapshots en el repositorio una vez subidos.
- Repository Purge By Retention Count: número de artefactos Snapshot que se mantienen en el repositorio.
- Releases Included: check que indica que el repositorio puede almacenar releases.
- Snapshots Included: check que indica que el repositorio puede almacenar snapshots.
- Scannable: check con el que permitimos que el repositorio pueda ser indexado para poder realizar búsqueda sobre él.
- Delete Released Snapshots: si se encuentra activado se eliminarán los snapshots cuando se suba la release del artefacto.
Figura 19. Creación de un repositorio gestionado.
Desde la opción "Add" situada en "Remote Repositories" añadiremos repositorios remotos.
- Identifier: identificador del repositorio.
- Name pequeña descripción.
- URL: dirección donde se encuentra situado el repositorio.
- Username: nombre del usuario para acceder al repositorio privado.
- Password: password del usuario para acceder al repositorio privado.
- Timeout in seconds: tiempo de espera para conectarse al repositorio antes de devolver un error.
- Type: naturaleza del tipo de artefactos almacenados en el repositorio (1.x o 2.x).
Figura 20. Creación de un repositorio remote.
3.10 Administration -> Proxy Connectors
Los Proxy Connectors, como hemos comentado antes, se utilizan para cachear artefactos de repositorios remotos en nuestras instalaciones, con la ventaja de reducir el tiempo de descarga a nuestro repositorio local y el tráfico que pudiera generar si todos los desarrolladores de una organización tuvieran configurado en sus ficheros settings.xml una conexión directa con los repositorios remotos.
La funcionalidad de un Proxy Connectors es supervisar las peticiones realizadas a repositorios gestionados y cachear los artefactos siguiendo una serie de políticas. Un Proxy Connector es una asociación entre un repositorio gestionado y un repositorio remoto. Para dar de alta uno debemos pulsar sobre el botón "Add" y rellenar el formulario:
- Network Proxy: tipo de conexión utilizada para descargar los artefactos. Puede ser una conexión directa o a través de un proxy.
- Managed Repository: repositorio gestionado donde se depositarán los artefactos descargados del repositorio remoto.
- Remote Repository: repositorio remoto que queremos cachear.
- Policies: parámetros que indican el comportamiento del proxy ante el almacenamiento de los artefactos remotos.
- Return error when: indica como se comporta Archiva cuando se produce un error en el proceso de acceso a un proxy remoto.
- Artifact no already present: debería retornar si existe un artefacto previamente cacheado.
- Always: siempre retorna el error.
- Cache failures: si se produce un error en el proceso de descarga podemos decidir si se cachea o no el artefacto.
- Releases: indica cada cuanto tiempo Archiva comprueba si hay una actualización del artefacto (never, once, hourly, dayly, always).
- On remote error: que comportamiento se toma cuando se produce un error en uno de los repositorios remotos definidos en el proxy connector:
- Stop: retorna el error inmediatamente.
- Queue error: espera a recorrer todos los repositorios remotos y retorna todos los errores.
- Ignore: descarta cualquier error.
- Checksum: con este parámetro definimos el comportamiento cuando el checksum de los artefactos descargados es incorrecto:
- Fail: produce un error.
- Fix: corrige el fichero de checksum.
- Ignore: se ignora.
- Snapshots: mismo comportamiento que la Releases.
- Return error when: indica como se comporta Archiva cuando se produce un error en el proceso de acceso a un proxy remoto.
Además de las politicas de almacenaje, podemos añadir filtros que nos permiten decidir que grupos pueden ser o no descargados a través de ese Proxy Connector.
Figura 21. Creación de un proxy connector.
3.11 Administration -> Legacy Support
Archiva es capaz de gestionar repositorios 1.x y 2.x. La estructura de los repositorios 1.x hace que Archiva necesite analizar el nombre de los artefactos para poder indexarlos y realizar búsquedas sobre ellos. Del análisis de los artefactos se recupera el identificador del mismo, la versión y el clasificador. En ocasiones puede que esta división sea errónea y provoque que el artefacto esté corrupto en el repositorio. Para solventar estos casos podremos definir reglas personalizadas a través de esta opción. Vamos a poner un ejemplo: imaginemos un artefacto almacenado en el path "adictos/jars/utilidades-1.0-FCS-full.jar". La división que Archiva realiza por defecto de este artefacto es:
- Grupo/: adictos
- Artefacto: utilidades
- Versión: 1.0
- Clasificador: FCS-full.
Si queremos que la Versión sea "1.0-FCS" y el clasificador "full" tendremos que dar de alta la siguiente regla:.
- Path: adictos/jars/utilidades-1.0-FCS-full.jar
- GroupId: adictos
- ArtifactId: utilidades
- Version: 1.0-FCS
- Classifier: full
- Type: jar
Figura 22. Creación de un mapeo de artefacto 1.x.
3.12 Administration -> Network proxies
En una gran mayoría de organizaciones se utilizan Proxies para acceder a Internet. En estos casos, todos los Proxy Connectors definidos que necesiten conexión a Internet para acceder a los artefactos deberan ser configurados con proxy.
Figura 23. Creación de un proxy.
3.13 Administration -> Repository Scanning
Desde "Repository Scanning" podremos configurar los patrones de ficheros que Archiva debe tener encuenta para considerar los ficheros como artefactos, ficheros que deben ser eliminados, ficheros que deben ser ignorados y ficheros que deben ser indexados. Además se pueden seleccionar los procesos que se ejecutarán cuando se escaneen los repositorios. Entre las tareas que podemos ejecutar se encuentra:
- auto-remove: eliminará los ficheros que coincidan con los patrones definidos en el apartado auto-remove.
- auto-rename: renombra posibles errores en los artefactos.
- create-missing-checksums: crea ficheros checksum md5 y sha1 en aquellos artefactos que no tengan.
- index-content: añade al directorio de indexación aquellos ficheros que coincidan con los patrones definidos en el apartado indexable-content.
- metada-updater: crea o actualiza los ficheros maven-metadata.xml.
- Repository-purge: elimina del repositorios los artefactos snapshots que no cumplan las reglas de purgación definidas en el repositorio.
- Update-db-artifact añade los artefactos a la base de datos.
- Validate-checksums valida los ficheros checksums contra los ficheros del repositorio.
Figura 24. Configuración tareas de escaneo.
3.14 Administration -> Database
De igual forma al anterior apartado, la opción "Dababase" nos permite configurar las tareas que deben ejecutarse en los procesos de purgación de los repositorios. Entre esas tareas podemos encontrar:
- update-db-bytecodes-stats: actualiza las estadísticas de los bytecodes de los artefactos.
- Index-public-methods: indexa todos los metodos públicos de los artefactos.
- Index-artefact: indexa todos los checksums de los artefactos.
- Validate-repository-metada: comprueba los ficheros metada del repositorio con la base de datos.
- Index-archive-toc: indexa la tabla de contenidos de archiva.
- Update-db-project: obtiene información de los pom pertenecientes a los artefactos y los almacena en la base de datos.
- Not-present-remove-indexed: elimina todos los contenidos indexados que no encuentre en el repositorio.
- Not-present-remove-db-artifact: elimina los artefactos de la base de datos si no estan presentes en el repositorio.
- Not-present-remove-db-project: elimina los proyectos de la base de datos que no se encuentren en el repositorio.
Figura 25. Configuración de tareas de base de datos.
4 RSS
Cualquier desarrollador podrá estar informado al instante de cualquier nuevo artefacto que se deposite en cualquiera de los repositorios que Archiva gestione. Para ello Archiva nos da la posibilidad de suscribirnos a dos tipos de RSS: por repositorio o por artefacto. Al primero nos suscribimos desde la opción de "Managment Repositories" y al segundo desde la opción "Browse".
5 Conclusión.
La utilización de este tipo de herramientas en organizaciones con gran número de desarrolladores, nos puede permitir reducir radicalmente el tráfico que se genera al descargar los artefactos de repositorios remotos.
Anímate y coméntanos lo que pienses sobre este tutorial
Puedes opinar o comentar cualquier sugerencia que quieras comunicarnos sobre este tutorial; con tu ayuda, podemos ofrecerte un mejor servicio.
| Autor | Mensaje de usuario registrado |
|---|
- Puedes inscribirte en nuestro servicio de notificaciones haciendo clic aquí.
- Puedes firmar en nuestro libro de visitas haciendo clic aquí.
- Puedes asociarte al grupo AdictosAlTrabajo en XING haciendo clic aquí.
- Añadir a favoritos Technorati.
Esta obra está licenciada bajo licencia Creative Commons de
Reconocimiento-No comercial-Sin obras derivadas 2.5
Recuerda
Autentia te regala la mayoría del conocimiento aquí compartido (Ver todos los tutoriales). Somos expertos en: J2EE, Struts, JSF, C++, OOP, UML, UP, Patrones de diseño ... y muchas otras cosas.
¿Nos vas a tener en cuenta cuando necesites consultoría o formación en tu empresa?, ¿Vas a ser tan generoso con nosotros como lo tratamos de ser con vosotros?
Somos pocos, somos buenos, estamos motivados y nos gusta lo que hacemos ...
Autentia = Soporte a Desarrollo & Formación.
Tutoriales recomendados
| Nombre | Resumen | Visitas | Valoración | Votos | ||
|---|---|---|---|---|---|---|
| JavaBean Datasource Ireport | La particularidad del caso que nos ocupa, es conseguir que la fuente de datos del informe sea una lista de JavaBeans y no una consulta definida previamente en el informe. | 2009-12-14 | 1260 | Bueno | 1 |  |
| Maven Assembly Plugin: empaquetando aplicaciones con Maven para la ejecución de procesos batch. | Examinamos cómo llevar a cabo el empaquetado de nuestras utilidades batch, basadas en una capa de servicios y cómo hacer la distribución independiente del entorno. | 2009-11-12 | 1317 | - | - | |
| Cómo conseguir que Subversion avise a Hudson para lanzar una build | En este tutorial vamos a ver como configurar Subversion para que sea este el que avise a Hudson cada vez que hay un commit, y así se lance la build. | 2009-10-27 | 2265 | - | - | |
| Cómo instalar Hudson en Apache Tomcat | Instalar Hudson en Apache Tomcat | 2009-10-26 | 2609 | Muy bueno | 1 | |
| Mavenizar Liferay SDK | En este tutorial vamos a ver unos sencillos pasos para poder hacer plugins de tipo portlet para Liferay adaptando el entorno de desarrollo Liferay Plugins SDK | 2009-09-27 | 1281 | Regular | 1 | |
| EJB 3.0 y pruebas unitarias con Maven, JUnit 4 y Apache Open EJB. | Continuamos buscando una buena solución para llevar a cabo test de EJBs, ahora con OpenEJB. | 2009-09-23 | 2436 | - | - | |
| EJB 3.0 y pruebas de persistencia con Maven, JUnit 4 y Embedded JBoss sobre Java 6. | Damos continuidad al tutorial EJB 3.0 y pruebas unitarias con Maven, JUnit 4 y Embedded JBoss Java 6, probando el llevar a cabo un test de persistencia de un EJB de entidad, bajo soporte de EJB de servicio que implementa el patrón dao, en el mismo entorno | 2009-09-14 | 2692 | Muy bueno | 1 | |
| Enlazar Bugzilla con MavenChangesPlugin | En este tutorial veremos como enlazar Bugzilla con MavenChangesPlugin | 2009-09-11 | 1156 | - | - | |
| Release Bugzilla Maven Plugin | En este tutorial vamos a mostrar como automatizar un conjunto de acciones que hay que hacer siempre en los sistemas de gestión de incidencias, tales como dar de alta una nueva versión del producto, cerrar las incidencias que soluciona la nueva versión, et | 2009-09-11 | 1395 | - | - | |
| Sobre las reglas de codificación o... ¿de dónde salen esos caracteres "raros"?. | En este tutorial vamos a tratar de dar algo de luz a los errores que tenemos habitualmente con la codificación de caracteres en aplicaciones en las que se ven implicados varios sistemas que intercambian o almacenan información. | 2009-09-08 | 4003 | Muy bueno | 1 | |
Nota:
Los tutoriales mostrados en este Web tienen como objetivo la difusión del conocimiento.
Los contenidos y comentarios de los tutoriales son responsabilidad de sus respectivos autores.
En algún caso se puede hacer referencia a marcas o nombres cuya propiedad y derechos es de sus respectivos dueños. Si algún afectado desea que incorporemos alguna reseña específica, no tiene más que solicitarlo.
Si alguien encuentra algún problema con la información publicada en este Web, rogamos que informe al administrador rcanales@adictosaltrabajo.com para su resolución.
