Ответ 1
Maven и Gradle - это предпочтительные способы использования Spring Framework в вашем проекте, но dist файлы по-прежнему доступны в официальном репозитории.
Я не загружал spring через некоторое время. Я изучаю gradle, но пока не вижу его, поэтому я хочу создать новый проект рамки spring, используя java, spring 4 и ant. Кажется, я не могу найти место для загрузки двоичных файлов для spring 4.
Они просто пинают ant разработчиков под шиной?
Maven и Gradle - это предпочтительные способы использования Spring Framework в вашем проекте, но dist файлы по-прежнему доступны в официальном репозитории.
Они просто пинают ant разработчиков под шиной?
Нет. Как упоминает Брайан , дистрибутивы по-прежнему доступны по адресу http://repo.spring.io для тех, кто не имеют другого варианта. ant пользователям рекомендуется интегрировать Ivy в свои скрипты сборки для управления зависимостями, чтобы им не нужны эти dist zips. Ivy способна работать с Maven-совместимыми хранилищами артефактов, чтобы обеспечить те же самые преимущества в области управления транзитивной зависимостью, что и Maven и Gradle. ant - идеальное решение для многих людей, и мы ожидаем, что оно будет продолжаться некоторое время. Тем не менее, ручное управление зависимостями, то есть загрузка dist zips, хранение банок на сетевом диске или проверка их на исходный контроль, широко понимается в отрасли как проблемный подход.
Мы считаем, что большинство пользователей Spring уже используют решения по управлению транзитивной зависимостью в той или иной форме. Мы по-прежнему предоставляем dist zips для тех, кто еще не смог принять эту практику, но, чтобы быть ясными, намеренно, что мы не предоставили этим специалистам первоклассное лечение на spring.io, которое они когда-то имели на springsource.org, потому что работа с dist zips - это просто худший способ управления зависимостями приложений.
Spring рассказывает о том, как команды разработчиков приложений устраняют излишнюю сложность. Есть несколько вещей, которые могут сделать разработку приложения более сложной и расстраивающей, чем "jar hell", которая возникает из ручного управления зависимостями. Вот лишь несколько примеров того, почему это может быть настолько болезненным:
Maven, Gradle и Ivy не являются серебряной пулей для всех проблем управления зависимостями, и, естественно, они приходят со своей сложностью и кривой обучения. Однако, когда выбор дает выбор, подавляющее большинство современных разработчиков приложений Java соглашаются с тем, что преимущества использования транзитивного управления зависимостями перевешивают их затраты.
Мы надеемся, что мы достигли правильного баланса в нашем подходе к руководству пользователями, как потреблять артефакты Spring. Мы осветили то, что мы (и большинство людей) считаем лучшими практиками в управлении зависимостями с помощью рекламы Maven и синтаксиса Gradle, но мы оставили дверь всем желающим, продолжая публиковать дистрибутивные zips. Однако мы обращаем внимание на обратную связь, чтобы убедиться, что этот подход действительно подходит большинству наших пользователей.
Дополнительную информацию по этой теме см. https://github.com/spring-projects/spring-framework/wiki/Downloading-Spring-artifacts.
И, как последнее замечание, мы иногда слышим от людей, что им нужны дистрибутивы, потому что их компания запрещает доступ к публичным репозиториям Maven, таким как Maven Central (http://search.maven.org) или репозиторий Spring (http://repo.spring.io). Это вполне понятно, но соответствующий ответ на эти ограничения заключается не в том, чтобы команды разработчиков в непроизводительных темных временах ручного управления зависимостями. Правильным решением является создание частного артефактного хранилища в корпоративном брандмауэре. Ведущими претендентами в этом пространстве являются JFrog Artifactory и Sonatype Nexus. Мы настоятельно рекомендуем, чтобы любая команда разработчиков по-прежнему вынуждала руководство по управлению зависимостями лоббировать свои команды архитектуры, чтобы изучить эти продукты и принять один из них. Преимущества для производительности, создания воспроизводимости и, действительно, способности компаний эффективно управлять зависимостями являются драматичными.
Вы можете использовать конфигурацию Maven, перейти к любому репозиторию Maven и загрузить JAR. Например:
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
</dependencies>
Сообщает мне посмотреть папку /org/springframework/ spring-context/4.0.0.RELEASE в любом репозитории Maven 2. Используя этот пример, я нашел это. Вы должны иметь возможность получить все JAR оттуда.
Вы можете найти информацию о зависимости для Spring 4 здесь
Оттуда вы можете загрузить двоичную банку и банку с источниками для ручного управления зависимостями.
Я нашел два источника: официальная страница загрузки здесь и OLEX.
Это вызвало много времени, пытаясь найти zip файлы через поисковые запросы на сайте Spring. Прямых ссылок на скачивание там больше нет.