Posts Tagged ‘dependencia’

h1

Chat de vídeo de Google Talk en OpenSUSE

28 septiembre 2010

Aunque Google ya proporciona un paquete RPM, supuestamente para dar soporte de manera sencilla a la videoconferencia en OpenSUSE, la realidad es que al final no es todo tan simple. El proceso inicial es el típico: la primera vez que intentemos iniciar el chat de voz/vídeo nos proporcionará un enlace desde el que descargar el paquete RPM. Sin embargo, cuando intentemos instalarlo avisará de que falta una dependencia libcrypto.so.10, que se encuentra dentro del paquete openssl.

Tras descargar este último (incluyendo también la versión de 32 bits si nuestro operativo es de 64), en lugar de instalar directamente el complemento de vídeo hay que crear dos enlaces simbólicos, porque a saber qué criterio de nombrado habrán utilizado en Google y por eso no encuentra la biblioteca que procede. Las órdenes son:

sudo ln -s /lib/libcrypto.so.1.0.0 /lib/libcrypto.so.10
sudo ln -s /lib/libssl.so.1.0.0 /lib/libssl.so.10

Ahora sí, podemos proceder a instalar el RPM, ignorando el error de dependencias que se muestre. Tras reiniciar el navegador ya deberíamos poder configurar los parámetros de la cámara 😀 Aviso de que a mí tampoco me funcionó a la primera, tuve que instalarlo primero en Chrome y después volver a probar desde Firefox. Tras este segundo intento ya funcionó sin problemas en ambos.

h1

Incluir JAR propio en un repositorio Maven local

24 marzo 2010

Una de las principales ventajas de Maven es que gestiona las dependencias de los proyectos descargándolas a un repositorio local la primera vez que se necesiten. Sin embargo, posiblemente tengamos que incluir algunas a mano porque no estén disponibles en los repositorios “oficiales”, como me ocurrió con Qt Jambi (editado: hoy he descubierto que hay un repositorio independiente en Sourceforge para la versión Community). Después de dar vueltas buscando una solución, resultó estar en las FAQ de Maven 🙂

Para incluir un artefacto debemos ejecutar una orden donde indicar cuál es el archivo a subir, su groupId, artifactId, versión, tipo de empaquetado y si debe generar el POM (no veo ningún motivo para no hacerlo), utilizando una orden como la siguiente. Nota: Si tenemos el ejecutable de Maven en el PATH podemos colocarnos en la carpeta donde se encuentre el artefacto para no tener que escribir toda su ruta.

mvn install:install-file -Dfile=qtjambi-4.5.0_01.jar -DgroupId=qtjambi -DartifactId=qtjambi -Dversion=4.5.0_01 -Dpackaging=jar -DgeneratePom=true

En este caso concreto el groupId y el artifactId coinciden porque me pareció más coherente, ya que se trata del JAR principal para cualquier aplicación que utilice Qt Jambi. Si también fuésemos a incluir las distribuciones para Windows, Mac y Linux podríamos hacerlo dentro del mismo groupId pero con distinto artifactId, como en las siguientes órdenes:

mvn install:install-file -Dfile=qtjambi-win32-msvc2005-4.5.0_01.jar -DgroupId=qtjambi -DartifactId=qtjambi-win -Dversion=4.5.0_01 -Dpackaging=jar -DgeneratePom=true
mvn install:install-file -Dfile=qtjambi-macosx-gcc-4.5.0_01.jar -DgroupId=qtjambi -DartifactId=qtjambi-mac -Dversion=4.5.0_01 -Dpackaging=jar -DgeneratePom=true
mvn install:install-file -Dfile=qtjambi-linux32-gcc-4.5.0_01.jar -DgroupId=qtjambi -DartifactId=qtjambi-linux -Dversion=4.5.0_01 -Dpackaging=jar -DgeneratePom=true
Y con esto tenemos cuatro nuevos JAR en nuestro repositorio local, listos para ser utilizados desde cualquier proyecto Maven 😀