Лично я бы постарался не проверять зависимости проекта в репозитории контроля версий SCM.Как правило, это происходит с использованием Maven, как предлагается в другом ответе, и развертыванием внутреннего репозитория Maven компании, который имеет преимущество, заключающееся в том, что этот ресурс является локальным для группы разработчиков, а также в месте, где могут находиться завершенные / проверенные / выпущенные артефакты вашего собственного проекта..
Проблема, с которой я вижу, что Jars является SCM, заключается в том, что в первую очередь SCM предназначен для управления исходным кодом , и они оптимизированы для этой цели.Скомпилированные артефакты не являются исходным кодом и являются двоичными файлами. Когда вы, как правило, разветвляете или обновляете двоичный файл, вы делаете копию двоичного файла, так как большинство SCM не может «различать» двоичный файл.
Другое соображениеЧто вы делаете, если у вас есть два проекта, которые нуждаются в проверке зависимостей?Вы регистрируетесь в каждом проекте отдельно и носите дубликаты?Или вы делаете третий проект, который содержит только зависимости?И теперь вы вручную управляете файлами jar в этом проекте.Что если вашим двум проектам требуются взаимно несовместимые зависимости?
В-третьих, как вы управляете межпроектными зависимостями (где один из ваших проектов зависит от другого)?Проверен ли файл jar из одного в другой?А как насчет контроля версий и других изменений?Вам просто нужно проверить два проекта и требовать, чтобы они были построены в строгом порядке?
По моему опыту и мнению, этих проблем обычно достаточно для разработки средней сложности, чтобы ответить на вопрос.окончательно: нет, нельзя проверять зависимости файла jar.Используйте систему сборки, такую как Maven или Ant + Ivy (или другую альтернативу), которая предоставляет способ для внешнего управления и хранения зависимостей из системы управления исходным кодом.