Un diseño para un proyecto maven con una dependencia parcheada

Question

Supongamos que tengo un proyecto de código abierto que depende de alguna biblioteca, que debe ser parcheado para solucionar algunos problemas. ¿Cómo puedo hacer eso? Mis ideas son:

1. Haga que las fuentes de la biblioteca se configuren como un módulo, guárdelas en mi vcs. Pros: simple. Contras: algunas fuentes de terceros en mi repositorio pueden ralentizar el proceso de compilación, es difícil encontrar un parche (aunque se puede solucionar en README)
2. Tiene un módulo, como en 1, pero solo mantiene los archivos fuente parcheados, compílelos con el contenedor de la biblioteca orignal en classpath y de alguna manera reemplazar los archivos * .class en el archivo jar de la biblioteca en la compilación. Pros: crea sitios parcheados más rápidos y fáciles de encontrar. Contras: difícil de configurar, el hacker de jar no es obvio (el jar de la biblioteca en el repositorio y en mi proyecto sería diferente)
3. Mantenga los archivos * .class parcheados en main/resources, y reemplace en el paquete como en 2). Pros: casi ninguno. Contras: binarios en vcs, difícil de recompilar una clase parche ya que la compilación de parches no está automatizada.

Una buena solución es crear un proyecto distinto con fuentes de biblioteca parcheadas, y desplegarlo en el repositorio local/empresarial con el calificador -patched. Pero eso no encajaría para un proyecto de fuente abierta que sea fácil de construir para cualquiera que controle sus fuentes. O debería simplemente decir "y también, antes de construir mi proyecto, por favor revise esas cosas y ejecute mvn install".

Answer 1

Una buena solución es crear un proyecto distinto con fuentes de biblioteca parcheadas, y desplegarlo en el repositorio local/empresarial con calificador -patched. Pero eso no encajaría para un proyecto de fuente abierta que sea fácil de construir para cualquiera que controle sus fuentes. O debería simplemente decir "y también, antes de construir mi proyecto, por favor revise esas cosas y ejecute mvn install".

Esto es lo que haría (y en realidad lo que hago) tanto para un proyecto corporativo como para uno de código abierto. Obtenga las fuentes, póngalas bajo control de versiones en un proyecto distinto, remóchelas, reconstruya la biblioteca parcheada (e incluya esta información en la versión, algo así como XYZ-patched), impleméntela en un repositorio (podría usar SVN para esto, a la Google Code), declare el repositorio en su POM y actualice la dependencia para que apunte a su versión parchada.

Con este enfoque, puede decirles a sus usuarios: revisen mi código y ejecuten mvn install y obtendrán la versión parchada sin ninguna acción adicional. Esto es en mi humilde opinión la forma más limpia (no propenso a errores, sin desorden de orden de ruta de clase, sin aumento del tiempo de compilación, etc.).

Mucha gente está implementando su código en su repositorio de subversión alojado (cómo hacerlo en this post).

Answer 2

Una buena solución es crear un proyecto distinto con fuentes de biblioteca parcheadas, y desplegarlo en el repositorio local/empresarial con calificador -patched. Pero eso no encajaría para un proyecto de fuente abierta que sea fácil de construir para cualquiera que controle sus fuentes. O debería simplemente decir "y también, antes de construir mi proyecto, por favor revise esas cosas y ejecute mvn install".

Estoy de acuerdo con esto y con la respuesta de Pascal.Algunas notas adicionales:

• puede usar dependency:unpack en el artefacto original y luego combinar eso con sus clases compiladas si no desea volver a generar todo el proyecto depende
• en cualquier caso, su pom.xml necesitarán represente correctamente las dependencias de esa biblioteca
• aún puede integrar esto como parte de la compilación de su proyecto para evitar el paso 'implementar en un repositorio'
• ¡asegúrese de cumplir con las limitaciones de la licencia del proyecto al hacer todo esto!