Расположение для проекта знатока с исправленной зависимостью
Предположим, у меня есть проект с открытым исходным кодом, который зависит от некоторой библиотеки, которая должна быть исправлена для устранения некоторых проблем. Как я делаю это? Мои идеи:
- Имейте ту библиотеку источники, настроенные как модуль, сохраните их в моем vcs. Профессионалы: простой. Недостатки: некоторые независимые источники в моем repo, мог бы замедлить процесс сборки, трудно для нахождения исправленного места (хотя может быть зафиксирован в README),
- Имейте модуль, как в 1, но сохраните исправленные исходные файлы только, скомпилируйте их с orignal банкой библиотеки в пути к классу и так или иначе замените *.class файлы в библиотеке, раздражают сборку. Профессионалы: сборки, быстрее, легкие найти исправленные места. Недостатки: трудно для конфигурирования то хакерство банки неочевидно (банка библиотеки в репозитории, и в моем блоке проекта отличалось бы),
- Сохраните исправленные *.class файлы в основном / ресурсах и замене при упаковке как в 2). Профессионалы: почти ни один. Недостатки: двоичные файлы в vcs, трудно для перекомпиляции исправленного класса, поскольку компиляция патча не автоматизирована.
Одно хорошее решение состоит в том, чтобы создать отличный проект с исправленными источниками библиотеки и развернуть его на локальном / репозитории предприятия с - исправленный спецификатор. Но это не соответствовало бы для opensourced проекта, который предназначен, чтобы быть легко buildable любым, кто проверяет его источники. Или если я просто говорю "и также, прежде чем Вы разработаете мой проект, проверьте тот материал и выполните установку mvn".
2 ответа
Одним из хороших решений является создание отдельного проекта с исправленными источниками библиотек и развертывание его в локальном/предпринимательском репозитории с квалификатором -patched. Но это не подходит для проекта с открытым исходным кодом, который должен быть легко собираемым для любого, кто проверит его исходные тексты. Или мне следует просто сказать: "И еще, прежде чем вы соберете мой проект, пожалуйста, проверьте этот материал и запустите mvn install".
Это то, что я бы сделал (и фактически делаю) как для корпоративного проекта, так и для проекта с открытым исходным кодом. Получить исходники, поместить их под контроль версий в отдельный проект, внести исправления, пересобрать исправленную библиотеку (и включить эту информацию в версию, что-то вроде X.Y.Z-patched), развернуть ее в репозитории (можно использовать SVN для этого, а-ля Google Code1), объявить репозиторий в POM и обновить зависимость, чтобы она указывала на вашу исправленную версию.
При таком подходе вы можете сказать своим пользователям: посмотрите мой код и выполните mvn install, и они просто получат исправленную версию без каких-либо дополнительных действий. IMHO это самый чистый способ (не приводит к ошибкам, не путает порядок путей классов, не увеличивает время сборки и т.д.).
1 Многие люди развертывают свой код в хостируемом репозитории subversion (как это сделать - в этом посте).
Хорошее решение - создать отдельный проект с исправленными исходными кодами библиотеки и развернуть его в локальном / корпоративном репозитории с квалификатором -patched. Но это не подходит для проекта с открытым исходным кодом, который должен быть легко построен любым, кто проверяет его исходный код. Или я должен просто сказать «а также, прежде чем строить мой проект, ознакомьтесь с этим и запустите mvn install».
Я согласен с этим и с ответом Паскаля. Некоторые дополнительные примечания:
- вы можете использовать
dependency: unpackна исходном артефакте, а затем объединить его с вашими скомпилированными классами, если вы не хотите перестраивать весь зависимый проект - в любом случае, ваш
pom.xmlдолжен будет правильно представлять зависимости этой библиотеки - , вы все равно можете интегрировать это как часть сборки вашего проекта, чтобы избежать шага «развертывание в репозиторий»
- , убедитесь, что вы при этом соблюдайте ограничения лицензии проекта!