Макет для проекта Maven с исправленной зависимостью - PullRequest
6 голосов
/ 12 апреля 2010

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

  1. Настройте исходники этой библиотеки как модуль, сохраните их в моем vcs. Плюсы: просто. Минусы: некоторые сторонние источники в моем репо могут замедлить процесс сборки, трудно найти исправленное место (хотя это можно исправить в README)
  2. Имейте модуль, как в 1, но сохраняйте только пропатченные исходные файлы, компилируйте их с помощью jar библиотеки orignal в classpath и каким-то образом заменяйте файлы * .class в jar библиотеки при сборке. Плюсы: строит быстрее, легко находит пропатченные места. Минусы: сложно настроить, что хакерство jar неочевидно (библиотека jar в репозитории и в моей сборке проекта будет отличаться)
  3. Сохраняйте исправленные файлы * .class в main / resources и заменяйте их на упаковке, как в 2). Плюсы: почти нет. Минусы: двоичные файлы в vcs, трудно перекомпилировать пропатченный класс, так как компиляция патчей не автоматизирована.

Одним из хороших решений является создание отдельного проекта с исправленными исходными библиотеками и его развертывание в локальном / корпоративном репозитории с квалификатором -patched. Но это не подходит для проекта с открытым исходным кодом, который может быть легко создан любым, кто проверяет его источники. Или я должен просто сказать «а также, прежде чем создавать мой проект, пожалуйста, проверьте этот материал и запустите mvn install».

Ответы [ 2 ]

6 голосов
/ 12 апреля 2010

Одним из хороших решений является создание отдельного проекта с исправленными исходными библиотеками и его развертывание в локальном / корпоративном хранилище с квалификатором -patched. Но это не подходит для проекта с открытым исходным кодом, который может быть легко создан любым, кто проверяет его источники. Или я должен просто сказать «а также, прежде чем строить мой проект, пожалуйста, проверьте все это и запустите mvn install».

Это то, что я бы сделал (и на самом деле то, что я делаю) для корпоративного проекта и проекта с открытым исходным кодом. Получите исходники, поместите их под контроль версий в отдельном проекте, исправьте их, пересоберите исправленную библиотеку (и включите эту информацию в версию, что-то вроде XYZ-исправлено), разверните ее в хранилище (вы можете использовать SVN для этого а-ля Google Code 1 ), объявите репозиторий в своем POM и обновите зависимость, чтобы она указала на вашу исправленную версию.

При таком подходе вы можете сказать своим пользователям: проверьте мой код и запустите mvn install, и они просто получат исправленную версию без каких-либо дополнительных действий. ИМХО это самый чистый способ (не подвержен ошибкам, нет путаницы с порядком пути классов, нет увеличения времени сборки и т. Д.).

1 Многие люди размещают свой код в своем размещенном хранилище Subversion (инструкции в этом посте ).

3 голосов
/ 12 апреля 2010

Одним из хороших решений является создание отдельного проекта с исправленными исходными библиотеками и его развертывание в локальном / корпоративном хранилище с квалификатором -patched. Но это не подходит для проекта с открытым исходным кодом, который может быть легко создан любым, кто проверяет его источники. Или я должен просто сказать «а также, прежде чем строить мой проект, пожалуйста, проверьте все это и запустите mvn install».

Я бы согласился с этим и с ответом Паскаля. Некоторые дополнительные примечания:

  • вы можете использовать dependency:unpack для исходного артефакта, а затем комбинировать его с вашими скомпилированными классами, если вы не хотите перестраивать весь зависимый проект
  • в любом случае ваш pom.xml должен будет правильно представлять зависимости этой библиотеки
  • вы все еще можете интегрировать это как часть сборки вашего проекта, чтобы избежать шага «развертывание в хранилище»
  • при выполнении всего этого убедитесь, что вы соблюдаете ограничения лицензии проекта!
...