maven 2 - pom - ¿La mejor práctica de Maven para generar tarros múltiples con clases diferentes/filtradas?

maven-compiler-plugin

Question

Desarrollé una biblioteca de utilidad de Java (similar a Apache Commons) que uso en varios proyectos. Además de clientes gordos, también lo uso para clientes móviles (PDA con el perfil de la Fundación J9). Con el tiempo, la biblioteca que comenzó como un único proyecto se extendió por múltiples paquetes. Como resultado, termino con mucha funcionalidad pero no realmente necesaria en todos los proyectos.

Dado que esta biblioteca también se usa dentro de algunos proyectos móviles / PDA, necesito una forma de recopilar solo las clases utilizadas y generar las jarras especializadas.

Actualmente, en los proyectos de ese área que usan esta biblioteca, tengo tareas Ant jar que generan (desde el proyecto de utilidad) los archivos jar especializados (por ejemplo: my-util-1.0-pda.jar, my-util-1.0-rcp.jar) utilizando funciones de tareas de jar incluir / excluir. Esto es más necesario debido a las restricciones de tamaño de jar generadas para los proyectos móviles.

Migrando ahora a Maven, me pregunto si hay algunas mejores prácticas para llegar a algo similar, así que considero los siguientes escenarios:

[1] - adicionalmente al artefacto de jar principal ( my-lib-1.0.jar ) que también genera dentro del proyecto my-lib los artefactos separados / especializados usando clasificadores (ej: my-lib-1.0-pda.jar ) usando Maven Jar Plugin o Maven Assembly Plugin filter / includes ... No estoy muy cómodo con este enfoque ya que contamina la biblioteca con las demandas de los consumidores de la biblioteca (filtros)

[2] - Crea proyectos Maven adicionales para todos los clientes / proyectos especializados, que "envolverán" el "my-lib" y generarán los artefactos de jar filtrados (por ejemplo: my-lib-wrapper-pda-1.0 ... etc.) . Como resultado, estos proyectos de envoltura incluirán el filtrado (para generar el artefacto filtrado) y dependerá solo del proyecto "my-lib" y los proyectos del cliente dependerán de my-lib-wrapper-xxx-1.0 en lugar de my- lib-1.0 . Este enfoque mi aspecto problemático ya que incluso eso dejará intacto el proyecto "my-lib" (sin clasificadores ni artefactos adicionales), básicamente duplicará el número de proyectos ya que para cada proyecto de cliente tendré uno solo para recopilar las clases necesarias de la biblioteca "my-util" (proyecto "my-pda-app" necesitará un proyecto / dependencia "my-lib-wrapper-for-my-pda-app")

[3] - En el proyecto de cada cliente que usa la biblioteca (por ejemplo: my-pda-app ) agrega algunos plugins Maven especializados para recortar (al generar el artefacto / paquete final) las clases innecesarias (por ejemplo: maven- assembly-plugin, maven-jar-plugin, proguard-maven-plugin)

¿Cuál es la mejor práctica para resolver este tipo de problemas de la "manera Maven"?

Answer 1

La regla general de Maven es "un artefacto primario por POM" en aras de la modularidad y las razones por las que uno no debería romper esta convención (en general) están muy bien explicadas en Cómo crear dos JAR a partir de un proyecto (... y por qué no deberías) publicar un blog. Sin embargo, existen excepciones justificadas (por ejemplo, un proyecto EJB que produce un EJB JAR y un cliente EJB JAR con solo interfaces). Habiendo dicho eso:

La publicación de blog mencionada (también consulte Usar Maven cuando no puede usar las convenciones ) explica cómo puede implementar la Opción 1 usando perfiles separados o el plugin JAR . Si decide implementar esta solución, tenga en cuenta que esto debería ser una excepción y que podría hacer que la administración de la dependencia sea más complicada (y, como usted mencionó, contaminará el proyecto con la "lógica de filtrado del cliente"). Por las dudas, utilizaría varias ejecuciones de plugins JAR aquí.

La opción 2 no es muy diferente de la Opción 1 IMO (excepto que separa las cosas): básicamente, tener N otros proyectos de envoltura / filtrado es muy similar al tener N reglas de filtrado en un proyecto. Y si el filtrado tiene sentido, prefiero la Opción 1.

No me gusta la Opción 3 en absoluto porque creo que no debería ser la responsabilidad de un cliente de una biblioteca "recortar" cosas no deseadas. Primero, un proyecto de cliente no necesariamente tiene el conocimiento requerido (qué recortar) y, segundo, esto podría crear un gran lío con otros complementos.

PERO si los clientes gordos no están utilizando todo el my-lib (como el código del lado del servidor requeriría todo el EJB JAR), entonces el filtrado no es el "camino correcto" para manejar su situación. El camino correcto sería la Opción 4 : poner todo lo común en un proyecto (produciendo my-lib-core-1.0.jar ) y partes específicas en proyectos específicos (que producirán my-lib-pda-1.0.jar, etc.). Los clientes luego dependerían del artefacto central y de los especializados.