La mejor estrategia para tratar con dependencias opcionales

Question

Actualmente estoy en el proceso de eliminar la dependencia de Spring de Flyway. En el futuro, podrían necesitarse otros tipos de dependencias para admitir un subconjunto de usuarios (como el soporte JBoss VFS).

¿Cuál es la mejor forma de admitir dependencias opcionales (opcional = verdadero en Maven POM)?

Cualidades de la solución serían:

• Facilidad de uso para los usuarios finales (trabajo mínimo necesario para utilizar la funcionalidad de si la dependencia está presente)
• Facilidad de uso para los desarrolladores (código de tratar con la dependencia opcional debe ser lo más fácil de leer y lo más sencillo posible)
• Sin dependencias requeridas innecesarias (si algún usuario final no necesita esta funcionalidad, no hay necesidad de tirar de la dependencia)

Answer 1

Creo que la funcionalidad de dependencia opcional de Maven es bastante limitada.

http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

dependencias opcionales no se derrumben (como dependencias transitivas) por defecto. Sin embargo, si sus usuarios necesitan usar estas características opcionales, las dependencias faltantes deben declararse explícitamente en su POM.

Personalmente, no me queda claro cómo esto ayuda a los usuarios ... Supongo que las dependencias opcionales en su POM sí documentan de qué versiones depende su código. Sin embargo, no todos los usuarios leerán el POM, todo lo que verán es el error "NoClassDef Found" :-(

Mi observación final es que este es uno de esos escenarios raros donde un administrador de dependencias como ivy ofrece más flexibilidad. Ivy tiene un concepto llamado "configuraciones" autores de módulos pueden montar diferentes combinaciones de las dependencias, por ejemplo "con resorte" o "sin-primavera"

Answer 2

Hay una opción de:..

• mantener el proyecto en un solo módulo y use dependencias opcionales.
• divide el proyecto en múltiples módulos; donde cada módulo tiene una dependencia (no opcional) en cualquier biblioteca;

Creo que lo primero tiene más sentido en la mayoría de los casos: los usuarios necesitan encontrar su camino en menos artefactos. Por lo general, deberán agregar menos dependencias nuevas a su pom. A menos que el código para admitir proyectos de terceros sea grande, esto también ayudará a mejorar los tiempos de descarga (menos viajes redondos). Con este último enfoque, puede encontrarse en situaciones incómodas donde el usuario ha definido su propio conjunto de versiones, pero solo para algunas de las dependencias de terceros.

Prefiero ver las dependencias opcionales en el pom (a veces miro para ver en qué versión está construido). Es cierto que algunas personas pueden no mirar. Creo que copiar y pegar fragmentos de pom en el sitio web es la mejor solución para eso. Por ejemplo, si tiene una página sobre la integración de Spring, puede poner el fragmento de pom relevante en esa página.

Sugeriría que las dependencias no libres (o cualquier cosa que no se pueda resolver fácilmente) se guarden en un módulo maven separado, para que los colaboradores siempre puedan construir el artefacto principal. (Tuve ese problema con Quartz, que IIRC tiene una dependencia opcional en un contenedor Oracle JDBC).

Editar: Si le preocupan los usuarios que ven NoClassDefFoundErrors, no haría ningún daño comprobar que la clase se puede resolver antes de intentar usarla. Por ejemplo, podría hacer una excepción y lanzar un mensaje de error más significativo que señale al usuario a la documentación. SLF4J es un buen ejemplo de esto.