Comprobación de archivos JAR (bibliotecas) en la herramienta de control de versiones: ¿es una buena práctica?

Question

Estoy desarrollando una aplicación web en Java y estoy usando varios archivos JAR de terceros en mi carpeta lib. También tengo Subversion como mi herramienta de control de versiones.

Mi pregunta es, al registrar mis archivos de proyecto, ¿debo registrar también los archivos JAR o no es necesario para versionar los archivos JAR ya que no los estoy modificando de todos modos?

Answer 1

Esta es una pregunta bastante subjetiva ... Por lo general, aplico la siguiente regla de oro: si tengo el código para construir un código binario, verifique el código, y nunca el binario; si se requiere un binario para ejecutar mi código y proviene de una fuente externa, compruebe el binario.

Tenga en cuenta que usted querrá cumplir con cualesquiera condiciones legales podrían venir junto con la comprobación de algún tercero binaria parte en su repositorio ..

Answer 2

Yo recomendaría que siempre que sea posible, se debe utilizar Maven. Entonces no necesitaría verificar JAR de terceros en su repositorio para compartirlos entre su equipo de desarrollo (la mayoría del tiempo).

Si no lo sabe, Maven realiza dos tareas principales: automatización de compilación y gestión de dependencias. Cada proyecto tiene un archivo descriptor que configura, entre otras cosas, qué JAR usas como dependencias. Lo bueno de eso es que Maven resolverá automáticamente las dependencias de esos JAR y sus dependencias, y así sucesivamente.

Answer 3

Gestiono los repositorios SVN para un equipo de desarrollo de tamaño mediano, y para facilitar su uso, los binarios de facturación que necesitamos; incluso el nuestro en algunos casos.

Creo que esto sigue siendo relevante, pero SVN históricamente ha tenido un desempeño deficiente con los binarios. Un desarrollador de Java en IBM se topó con este problema, investigó y escribió sus hallazgos. Puede que le resulte útil:

Performance tuning Subversion: Store and handle binaries without the performance drag

Aquí está la comida para llevar:

Los resultados de esta investigación son claramente específicos para el sistema siendo investigado, por lo que es poco probable que los valores reales que se muestran son de mucha importancia para otros sistemas. Los patrones son más importantes porque se replicarán en cualquier sistema de Subversion. De acuerdo con nuestros hallazgos , cuando se almacena un conjunto de binarios en Subversion:

• El método más eficiente en el tiempo es crear un único archivo comprimido que contiene el binario.
• El método que ahorra más espacio es utilizar la secuencia de comandos de check-in eficiente de Subversion en una estructura de directorio normal.
• El uso de cualquier forma de autenticación en el servidor de Subversion dará como resultado la pérdida de rendimiento.
• Una máquina dedicada y potente es óptima para ejecutar Subversion.

Answer 4

Personalmente me gustaría tratar de evitar la comprobación en las dependencias de un proyecto en el repositorio de control de versiones SMC.Típicamente eso sería usando Maven como se sugiere en otra respuesta y desplegando un repositorio Maven interno de la compañía que tiene la ventaja de hacer que este recurso sea local para el equipo de desarrollo y proporcionar una ubicación donde puedan residir los artefactos completados/versionados/liberados de su propio proyecto. .

El problema que veo con los Jars es que el SCM es el primero y más importante, el SCM es para administrar el código fuente y están optimizados para ese propósito. Los artefactos compilados no son código fuente y son binarios, cuando normalmente bifurca o actualiza el binario está haciendo una copia del binario, ya que la mayoría de los SCM no pueden 'diferir' un archivo binario.

Otra consideración es qué hacer si tiene dos proyectos que necesitan dependencias registradas? ¿Revisa los deps por separado en cada proyecto y usa la duplicación? ¿O haces un tercer proyecto que contiene solo las dependencias? Y ahora está administrando manualmente los archivos jar en ese proyecto. ¿Qué pasa si sus dos proyectos requieren dependencias mutuamente incompatibles?

En tercer lugar, ¿cómo gestionas las dependencias entre proyectos (donde uno de tus proyectos depende del otro)? ¿El archivo jar está registrado en el otro? ¿Qué pasa con las versiones y otros controles de cambio? ¿Simplemente tiene que sacar los dos proyectos y exigir que se construyan en estricto orden?

En mi experiencia y opinión, estos problemas suelen ser suficientes en un desarrollo de complejidad moderada para responder la pregunta definitivamente: No, no es aceptable verificar las dependencias de archivos jar. Use un sistema de compilación como Maven o Ant + Ivy (u otra alternativa) que proporcione una forma de externalizar la administración y el almacenamiento de las dependencias desde el sistema de control de código fuente.