타사 라이브러리 종속성에서 버그를 핫 고정합니다

Question 1

프로젝트를 별도로 구축 하고이 버전을 다른 네임 스페이스로 옮겼습니다. 이것은 분명히 드문 일이 아닙니다. 예를 들어, Hibernate는 API 변경으로 인한 버전 충돌을 피하기 위해 CGLIB를 자체 네임 스페이스로 유지합니다.

첫 번째 제안 된 솔루션은 내가 사용한 프로젝트가 다른 의존성에 사용되었을 때 문제가있었습니다. 정상 버전은 클래스 경로에 있었으며, 명명 충돌로 인해 매우 이상한 행동으로 이어졌습니다.
두 번째와 세 번째 제안은 첫 번째 제안과 비슷한 문제가있었습니다. 또한 다른 버전의 종속성과의 호환성을 깨뜨 렸습니다.

심지어 고통 스럽습니다. 네임 스페이스 밖으로 나가고 별도의 빌드를 제공하는 것은 몇 줄의 코드 만 변경하더라도 필수입니다.

Question 2

프로젝트의 의존성을 사용자 정의 네임 스페이스로 이동시키는 데 몇 가지 이유가 있다고 생각합니다.

수정은 종속성의 원래 개발자에게 다시 전송되지 않을 것입니다.
새로운 종속성 버전을 따라 잡기가 어려울 것이므로 더 이상 버그 픽스, 새로운 기능, 타사 개발자 및 기고자의 취약성 수정이 없습니다.
내 경험은 시간이 지남에 따라 잊혀진다는 것입니다 어떻게 그리고 왜 사용자 정의 네임 스펙팅 된 종속성이 수정되었습니다. 이로 인해 프로젝트 의이 부분은 감가 상각 될뿐만 아니라 만질 수 없을 것입니다.

Jitpack을 사용하는 워크 플로가 최상의 솔루션이라는 데 동의합니다. 몇 분만 오버 헤드로 수행하기위한 자세한 안내서가 포함 된 블로그 게시물을 썼습니다. https://5am.technology/2016/12/fix-bugs-third-party-dependency-jitpack/

Question 3

tl; dr;

방문 https://jitpack.io 그리고 그것이 어떻게 작동하는지 읽으십시오

제 3 자 라이브러리가 Github에 있다고 가정하고 프로젝트를 복제하고 수정하십시오.

그런 다음 사용하십시오 https://jitpack.io. Jitpack은 리포지토리에서 .jar를 생성합니다 (코드를 수정 한 위치).

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

또한이 원격 저장소를 명시 적으로 추가해야합니다

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>