archivos jar de Java en un repositorio (CVS, SVN ..)

Question

Por qué es una mala idea para cometer archivos jar de Java en un repositorio (CVS, SVN ..)

Answer 1

Debido a que puede reconstruirlos de la fuente. En la mano, si está hablando de archivos JAR de terceros requeridos por su proyecto, entonces es una buena idea enviarlos al repositorio para que el proyecto sea autónomo.

Answer 2

Ellos son archivos binarios:

• Es mejor hacer referencia a la fuente, ya que eso es lo que estás usando el control fuente de.
• El sistema no puede decirle qué diferencias entre los archivos
• Se convierten en una fuente de conflictos de combinación, en caso de que se compilan desde el origen en el mismo repositorio.
• Algunos sistemas (por ejemplo, SVN) no funcionan bien con archivos binarios grandes.

En otras palabras, mejor referencia a la fuente y ajuste sus scripts de compilación para que todo funcione.

Answer 3

La decisión de asignar archivos jar a SCM suele estar influenciada por la herramienta de compilación que se utiliza. Si usa Maven de manera convencional, entonces realmente no tiene la opción. Pero si su sistema de compilación le permite elegir, creo que es una buena idea enviar sus dependencias a SCM junto con el código fuente que depende de ellas.

Esto se aplica a jarras de terceros y jarras propias que se encuentran en un ciclo de lanzamiento separado para su proyecto. Por ejemplo, si tiene un archivo jar interno que contiene clases de utilidad comunes, me comprometo con SCM en cada proyecto que lo utiliza.

Si utiliza CVS, tenga en cuenta que no maneja los archivos binarios de manera eficiente. Un repositorio SVN no distingue entre archivos binarios y de texto.

http://svnbook.red-bean.com/en/1.5/svn.forcvs.binary-and-trans.html

actualización en respuesta a la respuesta publicado por Mark:

punto 1 WRT bala: Yo diría que no es muy común, incluso para un gran proyecto que tiene cientos de dependencias. En cualquier caso, el uso del disco (al mantener una copia separada de una dependencia en cada proyecto que lo usa) no debería ser su mayor preocupación. El espacio en disco es barato en comparación con la cantidad de tiempo perdido al tratar con las complejidades de un repositorio de Maven. En cualquier caso, un repositorio Maven local consumirá mucho más espacio de disco que las dependencias que realmente usa.

Bullet 3: Maven no le ahorrará tiempo esperando el tráfico de la red. El opuesto es verdad. Con sus dependencias en el control de código fuente, realiza un pago y luego pasa de una rama a otra. Muy rara vez tendrá que pagar los mismos tarros de nuevo. Si lo haces, tomará solo unos minutos. La razón principal por la que Maven es una herramienta de compilación lenta es todo el acceso a la red que hace, incluso cuando no es necesario.

Bullet Point 4: Su punto aquí no es un argumento en contra de almacenar tarros en SCM y Maven solo es fácil una vez que lo ha aprendido y solo es eficiente hasta el punto en que algo sale mal. Entonces se vuelve difícil y sus ganancias de eficiencia pueden desaparecer rápidamente. En términos de eficiencia, Maven tiene una pequeña ventaja cuando las cosas funcionan correctamente y una gran desventaja cuando no lo hacen.

Bullet Point 5: Los sistemas de control de versiones como SVN no guardan una copia por separado de cada versión de cada archivo. Los almacena de manera eficiente como deltas. Es muy poco probable que su repositorio SVN crezca a un tamaño "inmanejable".

viñeta Punto 6: Su punto aquí no es un argumento en contra de almacenar archivos es SCM. El caso de uso que mencione se puede manejar con la misma facilidad mediante una compilación Ant personalizada.

Answer 4

Los sistemas de control de fuente están diseñados para contener el código fuente del texto. Ellos pueden contener archivos binarios, pero eso no es para lo que están diseñados. En algunos casos, tiene sentido poner un archivo binario en control de fuente, pero las dependencias de Java generalmente se manejan mejor de una manera diferente.

La configuración ideal es aquella que le permite administrar sus dependencias fuera del control de la fuente. Debería poder gestionar sus dependencias fuera de la fuente y simplemente "señalar" la dependencia deseada desde dentro de la fuente. Esto tiene varias ventajas:

• Puede tener una serie de proyectos que dependen de los mismos binarios sin tener una copia por separado de cada binario. Es común que un proyecto de tamaño mediano tenga cientos de binarios de los que depende. Esto puede provocar una gran duplicación que desperdicia recursos locales y de respaldo.
• Las versiones de los binarios se pueden administrar de forma centralizada dentro de su entorno local o dentro de la entidad corporativa.
• En muchas situaciones, el servidor de control de origen no es un recurso local. Agregar un montón de archivos binarios ralentizará las cosas porque aumenta la cantidad de datos que se deben enviar a través de una conexión más lenta.
• Si está creando una guerra, puede que haya algunos frascos que necesite para el desarrollo, pero no despliegue, y viceversa. Una buena herramienta de administración de dependencias le permite manejar este tipo de problemas de manera fácil y eficiente.
• Si depende de un archivo binario que proviene de otro de sus proyectos, puede cambiar con frecuencia. Esto significa que podría sobrescribir constantemente el binario con una nueva versión. Como el control de versiones mantendrá todas las copias, podría crecer rápidamente a un tamaño inmanejable, especialmente si tiene algún tipo de integración continua o scripts de compilación automatizados que creen estos binarios.
• Un sistema de administración de dependencias ofrece un cierto nivel de flexibilidad en la forma de depender de los binarios. Por ejemplo, en su máquina local, es posible que desee depender de la última versión de una dependencia tal como se encuentra en su sistema de archivos. Sin embargo, cuando implementa su aplicación, desea que la dependencia se empaquete como un contenedor y se incluya en su archivo.

Las funciones de administración de dependencias de Maven solucionan estos problemas y pueden ayudarlo a localizar y recuperar dependencias binarias, según sea necesario. Ivy es otra herramienta que hace esto también, pero para Ant.

Answer 5

Por lo tanto, tiene un proyecto que utiliza algunas dependencias externas. Estas dependencias son bien conocidas. Todos ellos tienen

• Un grupo (por lo general, la organización/fragua crearlas)
• un identificador (su nombre)
• Una versión

En la terminología experta, estas informaciones se denominan coordenadas del artefacto (su Jarra).

Las dependencias de las que hablé son internas (para una aplicación web, puede ser su capa de servicio/dominio) o externas (log4j, controlador jdbc, marco Java EE, lo que sea, ...). Todas esas dependencias (también llamadas artefactos) son, de hecho, en su nivel más bajo, archivos binarios (JAR/WAR/EAR) que su CVS/SVN/GIT no podrá almacenar de manera eficiente. De hecho, SCM usa la hipótesis de que el contenido versionado, aquel para el cual las operaciones de diferencia son las más eficientes) es solo texto. Como consecuencia, cuando se almacenan datos binarios, rara vez se optimiza el almacenamiento (al contrario del texto, donde solo se almacenan las diferencias de versión).

Como consecuencia, lo que tendería a recomendar es utilizar un sistema de compilación de administración de dependencias, como maven, Ivy o Gradle. al usar dicha herramienta, declarará todas sus dependencias (de hecho, en este archivo, declarará las coordenadas de artefactos de sus dependencias) en un archivo de texto (o tal vez XML), que estará en su SCM. PERO sus dependencias no estarán en SCM. Más bien, cada desarrollador los descargará en su máquina de desarrollo.

Esto transfiere parte de la carga de red del servidor de SCM a Internet (que a menudo es más limitado que la red interna de enterpise), y se plantea la cuestión de la disponibilidad a largo plazo de artefactos. Ambas respuestas están resueltas (al menos en cualquier caso, pero creo que tanto Ivy como Gradle pueden conectarse a tales herramientas, y parece que se han formulado algunas preguntas sobre este tema) utilizando proxies de empresas, como Nexus, Artifactory y otros.

La belleza de estas herramientas es que ponen a disposición en la red interna una vista de todos los artefactos necesarios, yendo tan lejos como permitiéndole implementar sus propios artefactos en estos repositorios, haciendo que el intercambio de su código sea fácil e independiente del fuente (que puede ser una ventaja).

Para resumir esta larga respuesta: use Ivy/Maven/Gradle en lugar de simple Ant build. Estas herramientas le permitirán definir sus dependencias y hacer todo el trabajo de descargar estas dependencias y asegurarse de usar la versión declarada.

En una nota personal, el día que descubrí esas herramientas, mi visión del manejo de la dependencia en Java pasa de la pesadilla al cielo, ya que ahora solo tengo que decir que utilizo esta misma versión de esta herramienta, y maven (en mi caso), haga todo el trabajo de fondo para descargarlo y almacenarlo en la ubicación correcta en mi computadora.