#java #svn
#java #svn
Вопрос:
Я работаю с командой, которая скоро будет кодировать кучу Java-приложений в рамках более крупного проекта. Мы планируем использовать SVN для нашего исходного кода, но у нас будут зависимости от ряда других команд, которые НЕ используют SVN. В основном они будут кодировать ряд библиотек (в форме .jar), которые мы будем использовать в наших приложениях.
Я понимаю, что мы могли бы использовать svn: externals, если бы все были на SVN, но это не представляется возможным в ближайшем будущем. Сейчас мы, вероятно, будем просто получать обновленные файлы .jar от них примерно раз в неделю.
Я все еще относительно новичок в SVN, так какова надлежащая процедура для обработки этого? Проверяем ли мы их файл .jar в нашем репозитории? Или нам следует избегать наличия двоичных файлов в SCM подобным образом? Мы также исследовали использование управления зависимостями через Maven…это кажется хорошим вариантом для совместного использования двоичных файлов между командами, но я не уверен, действительно ли мы хотим что-то настолько сложное.
Комментарии:
1. Каково ваше текущее решение для сборки? Если он основан на ant, переход на Maven может быть довольно болезненным. В таком случае я бы предложил ivy для отслеживания зависимостей.
Ответ №1:
Я обнаружил, что управление зависимостями лучше всего выполнять с помощью репозитория maven или ivy. У Artifactory и Nexus есть бесплатные версии. Затем вы можете управлять ими из своего сценария сборки. Ivy, если вы используете Ant, Maven или Gradle. Я предпочитаю Gradle.
Комментарии:
1. Менеджер бинарных репозиториев — лучший способ (подключаемый модуль shameless: 1 для Artifactory); в специальных методах управления зависимостями, таких как VCS или сетевые ресурсы, отсутствуют многие важные функции (управление бинарными версиями, детализированная безопасность, проксирование и кэширование удаленных репозиториев, метаданных и многого другого).
2. Спасибо — после того, как я задал вопрос, я действительно смог запустить Maven. Было сложно настроить все правильно, но я вижу много преимуществ, когда это работает правильно. Мне придется поиграться с несколькими сценариями, чтобы понять, что проще всего для моей команды.
Ответ №2:
Проверка библиотек, особенно сторонних (в вашем случае, я думаю, вы можете назвать их сторонними), в SVN (или любом SCM) не имеет большого значения, и вы получаете так много преимуществ от простоты этого. Имейте в виду, что, если банки или библиотеки слишком велики и к тому же часто меняются, вы можете пойти на большую сложность (например, Maven, Ivy и т.д.)
И SVN хорош в обработке двоичных файлов и их различий.
Комментарии:
1. Может быть, Maven, который ничего не делает, кроме как собирает вместе последние версии библиотек, а затем выгружает их в SVN с упрощенными именами файлов без версий?
2. Спасибо — это в основном то, о чем я задавался вопросом. Библиотеки небольшие, так что это, вероятно, самый простой маршрут.
Ответ №3:
Я предлагаю прочитать о филиалах поставщиков:http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html
Комментарии:
1. Не знал об этой функции — возможно, она немного сложнее, чем то, что нам нужно, но удобно знать, что у SVN есть метод для этого.
Ответ №4:
Если пространство не является проблемой (на сервере) Я не думаю, что неправильно проверять двоичные файлы или даже исходный код ваших зависимостей. Это проще для всех, таким образом, люди могут просто проверять и создавать без особых проблем.
Ответ №5:
Если двоичные файлы большие, то я бы определенно не стал проверять их в репозитории. Мое предложение состояло бы в том, чтобы сохранить последнюю версию jars на общедоступном ресурсе, затем подключиться к этому ресурсу и связать его через файл проекта. Это означает, что только один человек должен был бы обновлять двоичные файлы вместо каждой машины, при условии, что пути к подключенному хранилищу остаются неизменными.
Если они не слишком велики, то нет ничего сложного в том, чтобы поместить их в репозиторий.