Pergunta

Encontrei um bug menor em uma estrutura de aplicativo maior que estou usando. A fixação exige apenas alterar duas linhas em uma única classe. Corrigi o problema e pressionei as alterações no repositório do projeto.

No entanto, preciso lançar amanhã. Portanto, não posso esperar até que a biblioteca esteja lançando uma nova versão. Estou me perguntando qual seria a melhor maneira de integrar a versão corrigida ao meu projeto:

  • Construa o projeto: acho que é bastante difícil, não posso nem construí -lo corretamente, pois tantos testes de unidade estão quebrados no repositório de instantâneos e mesmo sem os testes de unidade, não chego muito longe, pois obviamente estou perdendo algumas dependências que não podem ser encontradas em Maven Central. Além disso, preciso enviar a versão fixa para todos os outros desenvolvedores, pois ela não pode ser encontrada no Maven Central. (Trabalhamos na rede e não temos nosso próprio nexo.)

  • Adicionando um novo módulo ao meu projeto, onde mantenho uma cópia da classe que corrigi. Em seguida, adiciono este módulo como uma dependência a todos os módulos que devem usar a versão excedente da classe. Mas como a JVM está determinando qual classe ele realmente carrega? Vai encontrar dois jarra-Files que contêm uma classe com o mesmo nome. Qual deles ele realmente carregará? Se eu pudesse fazer isso funcionar, isso me permitiria integrar a versão modificada da classe ao meu projeto, de modo que eu pudesse distribuir o patch juntamente com o projeto e, uma vez que o bug seja corrigido, eu poderia simplesmente remover o módulo.

  • Estou incluindo o arquivo de classe modificado no próprio módulo afetado. Até agora, isso aparece como a solução mais fácil para mim, já que a JVM sempre carregará a classe do mesmo frasco primeiro. (Estou certo? Pelo menos é o que observei nos meus testes.)

Obrigado por qualquer contribuição sobre isso.

Foi útil?

Solução

Acabei construindo o projeto separadamente e movendo esta versão para outro espaço para nome. Aparentemente, isso não é tão incomum. Por exemplo, o Hibernate mantém o CGLIB em seu próprio espaço para nome para evitar conflitos de versão devido a alterações na API.

  • A primeira solução sugerida teve um problema quando o projeto que usei também foi usado em outra dependência que levou a essa minha versão modificada e a normal A versão estava no caminho da classe, o que levou a um comportamento muito estranho devido a conflitos de nomeação.

  • A segunda e a terceira sugestão tiveram problemas semelhantes aos da primeira sugestão. Além disso, quebrei a compatibilidade com outras versões da dependência.

Mesmo parece doloroso: sair do espaço para nome e fornecer uma construção separada é uma obrigação, mesmo que você altere apenas algumas linhas de código.

Outras dicas

Eu acho que mover dependências do seu projeto em namespaces personalizados não é ideal, por vários motivos:

  • Suas modificações provavelmente não serão enviadas de volta aos desenvolvedores originais da dependência.
  • Será difícil acompanhar as novas versões de dependência, portanto, não há mais bugs, sem novos recursos, sem correções de vulnerabilidade de desenvolvedores e colaboradores de terceiros.
  • Minha experiência é que, com o tempo, é esquecido Como as e Por quê A dependência namespact personalizada foi modificada. Isso resultará nessa parte do projeto não apenas depreciado, mas também intocável, pois ninguém saberá o que será quebrado ao substituí -lo.

Concordo que um fluxo de trabalho usando Jitpack é a melhor solução. Escrevi um post com um guia detalhado para fazê -lo com apenas alguns minutos de sobrecarga: https://5am.technology/2016/12/fix-bugs-third-party-dependence-jitpack/

Tl; dr;

Visita https://jitpack.io e leia como funciona


Passos para resolver o problema

Supondo que a biblioteca de terceiros esteja no Github, basta clonar o projeto e consertá-lo.

Em seguida, use https://jitpack.io. Jitpack cria um .jar a partir do seu repo (onde você corrigiu o código) e gera uma dependência para você gostar

<dependency>
    <groupId>GITHUB_USER</groupId>
    <artifactId>REPOSITORY</artifactId>
    <version>COMMIT</version>
</dependency>

Além disso, você precisa adicionar explicitamente este repositório remoto

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>
  • Trabalho rápido
  • Simples de fazer
  • Simples de desfazer
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top