Évitez les conflits de versions de dépendances?

Tout projet Java qui utilise mon pot, aura presque certainement une dépendance supplémentaire par rapport à un autre pot, que mon pot contient également en tant que dépendance.

Le problème est que l'autre pot a plusieurs versions.

Comment puis-je éviter les problèmes qui pourraient survenir, dans le cas probable où la version de votre projet du 2e pot est différente de la version de mon pot du 2e pot?

Je ne veux pas que mes utilisateurs aient le tracas supplémentaire de faire une astuce de chargement de classe pour ajouter mon pot.

Dois-je simplement créer un tas de versions différentes de mon pot, pour chaque version possible de cette dépendance commune? Et puis vous choisissez simplement la version de mon pot qui utilise la même version du 2ème pot que vous avez déjà?

Existe-t-il un moyen plus intelligent de gérer cela et de faciliter l'utilisation des pots sans conflits par les gens?

Ce n'est pas votre problème. C'est à votre utilisateur final de le résoudre. Cela vient avec le territoire d'utilisation des dépendances tierces, et j'ai dû résoudre les conflits de dépendance plus de fois que je ne compte. Vous ne pouvez pas vous attendre à gérer les conflits de dépendance spécifiques à chaque projet.

Votre logiciel devrait fonctionner correctement avec les dernières versions de vos dépendances. À moins que la dépendance ne change d'interface à chaque version, vous devriez avoir une gamme de compatibilité (par exemple, votre logiciel fonctionne pour toutes les versions de dep dans la gamme [2.0.0, 3.0.0)). Tant que vous maintenez le logiciel, vous devez essayer de le garder compatible avec la dernière version de toutes vos dépendances.

Cela dit, voici certaines choses que je trouverais utiles en tant que développeur utilisant votre logiciel avec ma version différente de votre dépendance.

• Si l'intégration entre votre projet et un autre projet est étroite, il est utile d'avoir un tableau de compatibilité dans votre documentation. Quoi qu'il en soit, vous devez mentionner tout problème connu avec des versions spécifiques de la dépendance dans votre documentation. Sinon, les développeurs doivent trouver une version compatible par essais et erreurs.
• Abstenez la collaboration avec la dépendance via une interface et concevez votre logiciel afin que l'implémentation puisse être remplacée par une injection de dépendance. Cela me permet en tant qu'utilisateur final de substituer ma propre intégration à la version x de la bibliothèque sans vous déranger.
• Disposez d'un outil de suivi des problèmes publics afin que vos utilisateurs puissent vous demander de prendre en charge certaines versions de la dépendance commune. Si vous trouvez que de nombreux utilisateurs souhaitent prendre en charge une version incompatible de la dépendance, vous pouvez publier des versions pour les deux. Voir cet exemple Maven où ils ciblent plusieurs plates-formes - la prise en charge des différentes versions d'une dépendance devrait être similaire.