Repositorios de artefactos Maven: Archiva vs Nexus

nexus-real-logo-300x99Actualmente en mi empresa usamos Archiva como gestor de repositorios Maven, pero leyendo esta mañana las novedades diarias del grupo de Ecosistemas Software en Google y el más que interesante análisis de Sonatype Nexus por parte de uno de los miembros del equipo de Apache Archiva me hacen como poco reflexionar sobre esta herramienta y el darle una oportunidad en nuestro ecosistema. Realmente ya conocía que Nexus está mejor integrada a nivel de Eclipse que Archiva, pero las métricas que aporta Arnaud no dan lugar a dudas.

Uno de los párrafos que debo mencionar es sin duda:

“how could I say something other than… migrate! It’s unfortunate for me to have to admit this as a member of the Archiva team, but my own research proves it. Nexus is a product of great quality, which delivers the service you need for your development projects very well. Furthermore, developed by full-time employees (thank you Sonatype), it enjoys an easily accessible and responsive support (I recommend the channel #nexus on #irc.codehaus.org). Archiva itself is governed by the laws of open source, suffers from the lack of time of its maintainers (even if they are doing as much as they can) which doesn’t help it to stay in the competition.”

Sinceridad no se le puede negar desde luego.

Recomiendo la lectura del artículo completo.

Y vosotros, conoceis o usais Nexus en vuestro ecosistema software ? Qué opiniones positivas o negativas teneis al respecto ? En nuestro caso, debo reconocer que Archiva siempre ha cumplido su labor muy dignamente aunque si es cierto que su consumo de memoria pueda ser excesivo sobre todo cuando coinciden una serie de subidas simultáneas de artefactos importantes (fundamentalmente EAR´s).

Maven y librerías de terceros (jms, jmxri, jmxtools, …)

Un problema común que podemos encontrar al usar Maven es que Sun no permite distribuir sus jar, por lo que oficialmente no se puede poner simplemente la dependencia en nuestros ficheros pom.xml usando repositorios públicos como hacemos con la mayoría. De ese modo, en los repositorios maven que hay por el mundo, no están estos jar de Sun MicroSystems, así que maven no se los puede bajar, al menos automáticamente. Hay que bajárselos a mano y ponerlos en tu repositorio local de maven (o en uno a nivel departamental, corporativo, … esto ya depende de la configuración concreta que tengamos en Maven).

Bien, ¿Cómo instalar un jar de terceros en nuestro repositorio? Podemos encontrar más información al respecto en la siguiente página:

http://maven.apache.org/guides/mini/guide-installing-3rd-party-jars.html

Por ejemplo, para el caso de jms.jar, jmxri.jar, y jmxtools.jar, de las que en nuestros IDE nos encontraremos con bonitos errores del estilo: “Missing Artifact required …” las líneas quedarían del siguiente modo:

mvn install:install-file -Dfile={RUTA_JAR}/jms.jar -DgroupId=javax.jms -DartifactId=jms -Dversion=1.1 -Dpackaging=jar
mvn install:install-file -Dfile={RUTA_JAR}/jmxri-1.2.1.jar -DgroupId=com.sun.jmx -DartifactId=jmxri -Dversion=1.2.1 -Dpackaging=jar
mvn install:install-file -Dfile={RUTA_JAR}/jmxtools-1.2.1.jar -DgroupId=com.sun.jdmk -DartifactId=jmxtools -Dversion=1.2.1 -Dpackaging=jar

siendo {RUTA_JAR} la ruta física donde nos hemos descargado los ficheros jar correspondientes.

Otro tema distinto es que tengamos problemas con la librería tools.jar. En este caso, el proyecto se quejará de esta dependencia:

com.sun:tools:jar:1.5.0 (la versión puede diferir según el entorno).

Y claro, esa dependencia no existe en ningún repositorio. ¿Cuál es el problema? El problema es que Eclipse está usando para compilar un JRE, no un JDK. Para resolverlo nada más simple que decirle que use el JDK que queramos:

Windows -> Preferences -> Java -> Installed JRE’s -> Add

Y añadimos una nueva entrada que apunte a la ruta del JDK y la marcamos para que la use por defecto.