Evitar conflitos de versão de dependência?


10

Qualquer projeto Java que use meu jar, certamente terá uma dependência adicional de outro jar, que meu jar também contém como dependência.

O problema é que esse outro jar possui várias versões.

Como evitar problemas que possam surgir, no caso provável de a versão do segundo jar do seu projeto ser diferente da versão do segundo jar do meu jar?

Não quero que meus usuários tenham o trabalho extra de fazer algum truque sofisticado de carregamento de classe para adicionar meu jar.

Devo apenas criar um monte de versões diferentes do meu jar, para todas as versões possíveis dessa dependência comum? E então você acabou de escolher a versão do meu jar que usa a mesma versão do segundo jar que já possui?

Existe uma maneira mais inteligente de lidar com isso e facilitar o uso do meu jar sem conflitos?

Respostas:


10

Não é problema seu . Cabe ao seu usuário final resolver. Ele vem apenas com o território de usar dependências de terceiros, e eu tive que resolver conflitos de dependência mais vezes do que considero. Você não pode esperar acomodar conflitos de dependência específicos de cada projeto.

Seu software deve funcionar corretamente com as versões mais recentes de suas dependências. A menos que a dependência mude sua interface em cada versão, você deve ter uma gama de compatibilidade (por exemplo, seu software funciona para todas as versões do dep in range [2.0.0, 3.0.0)). Enquanto você estiver mantendo o software, tente mantê-lo compatível com a versão mais recente de todas as suas dependências.

Dito isto, aqui estão algumas coisas que eu consideraria úteis como desenvolvedor usando o seu software com a minha versão diferente da sua dependência.

  • Se a integração entre o seu projeto e outro for difícil, é útil ter um gráfico de compatibilidade em sua documentação. Independentemente disso, você deve mencionar quaisquer problemas conhecidos com versões específicas da dependência em sua documentação. Caso contrário, os desenvolvedores devem encontrar uma versão compatível por tentativa e erro.
  • Abstraia a colaboração com a dependência por meio de uma interface e projete seu software para que a implementação possa ser substituída pela injeção de dependência. Isso me permite, como usuário final, substituir minha própria integração pela versão x da biblioteca sem incomodá-lo.
  • Tenha um rastreador de problemas público para que seus usuários possam solicitar que você ofereça suporte a determinadas versões da dependência comum. Se você achar que muitos usuários desejam suporte para uma versão incompatível da dependência, poderá publicar versões para ambos. Veja este exemplo do Maven onde eles têm como alvo várias plataformas - o suporte para diferentes versões de uma dependência deve ser semelhante.

O Java tem algo parecido com a configuração bindingRedirect App.config do assembly no .NET, onde você pode especificar "bibliotecas que solicitam dependência O Foo v3.0.2 deve realmente usar o Foo v3.0.5 e fingir que é a v3.0.2"? Eu não faço Java há mais de 11 anos, então minha memória de como ele lida com isso acabou.
John Zabroski 19/03/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.