Горячий фиксирование ошибки в сторонней библиотечной зависимости

Question

Я нашел незначительную ошибку в большей структуре приложений, которую я использую. Исправление требует только для того, чтобы изменить две линии в одном классе. Я исправил проблему и вставил изменения в хранилище проекта.

Тем не менее, мне нужно выпустить завтра. Поэтому я не могу ждать, пока библиотека не выпустит новую версию. Мне интересно, что будет лучшим способом интеграции исправленной версии в мой проект:

• Создайте проект: это я нахожу довольно сложным, я даже не могу построить его должным образом, так как так много модульных тестов разбиты в репозитории снимка, и даже без модульных тестов я не очень далеко, так как я, очевидно, упускаю некоторые зависимости, которые не могут быть найдены в Maven Central. Кроме того, мне нужно отправить фиксированную версию для любого другого разработчика, поскольку ее нельзя найти на Maven Central. (Мы работаем над сетью, и у нас нет собственной Nexus.)

• Добавление нового модуля в свой проект, где я храню копию класса, который я исправил. Затем я добавляю этот модуль в качестве зависимости ко всем модулям, которые должны использовать версию класса с переопределением. Но как JVM определяет, какой класс он на самом деле загружается? Он найдет два банка-Пы, которые содержат класс с тем же именем. Какой из них он на самом деле загрузит? Если бы я мог сделать эту работу, это позволило бы мне интегрировать модифицированную версию класса с моим проектом, чтобы я мог распределить патч вместе с проектом, и как только ошибка будет исправлена, я мог бы просто удалить модуль.

• Я включаю модифицированный файл класса в сам пораженный модуль. До сих пор это кажется самым простым решением для меня, так как JVM всегда будет загружать класс с одной и той же банки. (Я прав? По крайней мере, это то, что я наблюдал в своих тестах.)

Спасибо за любой вклад по этому поводу.

Answer 1

Я закончил тем, что построил проект отдельно и перенес эту версию в другое пространство имен. Это, очевидно, не так редко. Например, Hibernate сохраняет CGLIB в своем собственном пространстве имен, чтобы избежать конфликтов версий из -за изменений API.

• Первое предложенное решение имело проблему, когда использовался проект, который я использовал, также использовался в другой зависимости, что привело к тому, что моя модифицированная версия и обычный Версия была на пути класса, что привело к очень странному поведению из -за конфликтов именования.

• Второе и третье предложение имели аналогичные проблемы, что и первое предложение. Кроме того, я прервал совместимость с другими версиями зависимости.

Даже это звучит болезненно: выход из пространства имен и предоставление отдельной сборки является обязательным, даже если вы измените только несколько строк кода.

Answer 2

Я думаю, что перемещение зависимостей вашего проекта в пользовательские пространства имен не оптимально по нескольким причинам:

• Ваши модификации, скорее всего, не будут отправлены обратно первоначальным разработчикам зависимости.
• Будет трудно идти в ногу с новыми версиями зависимостей, поэтому больше нет ошибок, нет новых функций, никаких исправлений уязвимости от сторонних разработчиков и участников.
• Мой опыт в том, что со временем он забывается как а также Почему Зависимость на индивидуальной именах была изменена. Это приведет к тому, что эта часть проекта будет не только устаревшей, но и неприкасаемой, поскольку никто не узнает, что сломается при его замене.

Я согласен, что рабочий процесс, использующий Jitpack, является лучшим решением. Я написал сообщение в блоге с подробным руководством, чтобы сделать это всего лишь пару минут накладных расходов: https://5am.technology/2016/12/fix-bugs-third-party-depectendency-jitpack/

Answer 3

TL; DR;

Посещать https://jitpack.io и прочитайте, как это работает

---

Шаги для решения проблемы

Предположим, что сторонняя библиотека находится на 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>

• Быстрая работа
• Просто сделать
• Просто отменить