2012-07-25 8 views
8

Según tengo entendido, Nexus es responsable de almacenar los archivos JAR que hacen referencia a otros JAR de dependencia a través de su pom. Y, a su vez, los archivos JAR originales también se pueden usar como dependencias.¿Es Nexus el lugar correcto para archivar las versiones (jar-with-depencies, WAR, tar.gz, zip, etc.)?

Sin embargo, ¿deberíamos almacenar artefactos de liberación en Nexus? Estos son archivos que nunca se usarán como dependencias. Incluyen jar-with-dependence, WAR, zip/tar.gz, etc. ¿Cuál es el lugar correcto para almacenarlos?

Un simple servidor HTTP del sistema de archivos como http://archive.apache.org/dist/ parece ser la idea correcta. Pero Nexus es solo un administrador además de eso.

+0

Depende. Si el artefacto de su proyecto es algo más grande que el conjunto de frascos y guerras, entonces podría estar bien almacenarlo allí. Diría que si es conveniente con esta idea, ¿por qué no? Almacenamos archivos comprimidos para algunos de nuestros proyectos. –

+0

Pregunta realmente interesante :) +1 –

Respuesta

7

Nexus es definitivamente un buen lugar para almacenar estos artefactos, ya que ha evolucionado mucho más allá de un servidor de repositorio Maven puro. Te ofrece una interfaz de usuario agradable para descarga, seguridad y mucho más.

Si ya está usando Nexus, definitivamente no perdería tiempo con otro servidor o componente de infraestructura para almacenar estos artefactos. Especialmente también si estás construyendo tus artefactos con Maven. El despliegue viene casi gratis entonces ...

0

Estoy de acuerdo con Manser.

Desde mi punto de vista, cada vez que suelte algo, debe estar en su repositorio (Nexus, Archiva, Artifactory, lo que quiera).

Esto es cierto para los repositorios empresariales, pero especialmente cuando publica algo en Internet, para mantener una versión construida lista para usar (y no lista para compilar;) ese es su trabajo SCM). Incluso es un contenedor con dependencias, es una forma conveniente de distribuir su lanzamiento.

El único punto malo es que ocupa un lugar importante en el repositorio, duplicando frascos (para guerra, oído o jar-with-dependence). Pero es (en este momento) esta única forma de tener una versión completa lista para ejecutarse.

Cuestiones relacionadas