Итак, у вас есть проект, который использует некоторые внешние зависимости. Эта зависимость хорошо известна. Все они имеют
- Группа (обычно организация / кузница, создающая их)
- Идентификатор (их имя)
- версия
В терминологии maven эта информация называется координатами артефакта (вашего Jar).
Зависимости, о которых я говорил, являются внутренними (для веб-приложения, это может быть уровень службы / домена) или внешними (log4j, драйвер jdbc, среда Java EE, вы называете это, ...). Все эти зависимости (также называемые артефактами) на самом деле являются на самом низком уровне двоичными файлами (JAR / WAR / EAR), которые ваш CVS / SVN / GIT не сможет эффективно хранить. Действительно, SCM использует гипотезу, что версионный контент, для которого операции diff наиболее эффективны), является только текстовым. Как следствие, когда хранятся двоичные данные, их редко можно оптимизировать для хранения (в отличие от текста, где хранятся только различия версий).
Как следствие, я бы рекомендовал вам использовать систему построения управления зависимостями, такую как maven , Ivy или Gradle . Используя такой инструмент, вы объявите все свои зависимости (фактически, в этом файле вы объявите координаты артефактов ваших зависимостей) в текстовом (или, возможно, XML) файле, который будет в вашем SCM. НО ваши зависимости не будут в SCM. Скорее, каждый разработчик будет загружать их на свой компьютер разработчика.
Это передает некоторую сетевую нагрузку с сервера SCM в Интернет (полоса пропускания которого часто более ограничена, чем внутренняя сеть предприятия) и задает вопрос о долгосрочной доступности артефактов. Оба эти ответа решены (по крайней мере, в работе amven, но я полагаю, что и Ivy, и Gradle могут подключаться к таким инструментам - и, похоже, некоторые вопросы были заданы именно по этой теме) с использованием корпоративных прокси, например Nexus , Артефактория и др.
Прелесть этих инструментов в том, что они делают доступными во внутренней сети просмотр всех необходимых артефактов, вплоть до того, что позволяют вам развертывать ваши собственные артефакты в этих репозиториях, делая совместное использование вашего кода простым и независимым от источника. (что может быть преимуществом).
Подводя итог этому длинному ответу: используйте Ivy / Maven / Gradle вместо простой сборки Ant. Эти инструменты позволят вам определить ваши зависимости и выполнить всю работу по загрузке этих зависимостей и гарантировать, что вы используете объявленную версию.
В личной заметке, в день, когда я обнаружил эти инструменты, мое видение обработки зависимостей в Java перешло от кошмара к небу, так как теперь мне остается только сказать, что я использую именно эту версию этого инструмента, и maven (в моем дела), выполните всю фоновую работу по загрузке и хранению в нужном месте на моем компьютере.