我已经有一段时间没有下载spring了。我正在研究 gradle，但似乎还没有掌握它的窍门，所以我想使用 java、Spring 4 和 ant 创建一个新的 spring 框架项目。我似乎找不到下载 Spring 4 二进制文件的地方。
他们只是把蚂蚁开发者踢到公共汽车下面吗？
他们只是把蚂蚁开发者踢到公共汽车下面吗？
不，正如布莱恩mentions https://stackoverflow.com/a/20630626/622403，分发 zip 仍然可以在http://repo.spring.io http://repo.spring.io对于那些没有其他选择的人。我们鼓励 Ant 用户将 Ivy 集成到他们的构建脚本中来管理依赖项，这样他们就不需要这些 dist zip。 Ivy 能够与 Maven 兼容的工件存储库配合使用，以提供与 Maven 和 Gradle 相同的传递依赖管理优势。对于许多人来说，Ant 是一个完美的构建解决方案，我们预计它会持续一段时间。然而，手动管理依赖项，即下载 dist zip、将 jar 存储在网络驱动器上或将其签入源代码管理，在业界被广泛认为是一种有问题的方法。
我们相信大多数 Spring 用户已经以某种形式使用传递依赖管理解决方案。我们继续为那些尚未能够采用这种做法的人提供 dist zip，但要明确的是，我们故意没有在 spring.io 上为这些 dist zip 提供他们曾经在 springsource 上享有的一流待遇.org，因为使用 dist zips 是管理应用程序依赖项的一种较差的方法。
Spring 旨在帮助应用程序开发团队消除不必要的复杂性。没有什么比手动依赖管理带来的“jar 地狱”更能让应用程序的开发变得更加复杂和令人沮丧了。以下是为什么这会如此痛苦的几个例子：
- 需要连接到存储 jar 的网络驱动器（因此，通常需要连接到公司 VPN）；
- 或者，在将 jar 签入存储库的情况下，需要管理大量、笨重的存储库，通常会导致不同存储库中相同 jar 的许多重复；
- 没有简单、通用且可靠的方法来 (a) 了解依赖项的版本是什么，更重要的是 (b) 了解该依赖项的该版本是否与应用程序依赖关系图中的所有其他 jar 兼容。
Maven、Gradle 和 Ivy 并不是解决所有依赖管理问题的灵丹妙药，它们自然也有自己的复杂性和学习曲线。然而，当有选择时，绝大多数现代 Java 应用程序开发人员都认为使用传递依赖管理的好处超过了其成本。
我们希望我们在指导用户如何使用 Spring 工件的方法中取得了适当的平衡。通过宣传 Maven 和 Gradle 语法，我们已经将焦点放在了我们（和大多数人）认为是依赖管理最佳实践的方面，但我们通过继续发布发行版 zip 向所有来者敞开了大门。然而，我们正在关注反馈，以确保这种方法实际上适合我们的大多数用户。
有关此主题的更多信息，请参阅https://github.com/spring-projects/spring-framework/wiki/Downloading-Spring-artifacts https://github.com/spring-projects/spring-framework/wiki/Downloading-Spring-artifacts.
最后一点，我们有时会听到人们说他们需要发行版 zip，因为他们的公司不允许访问公共 Maven 存储库，例如 Maven Central (http://search.maven.org http://search.maven.org）或 Spring 存储库（http://repo.spring.io http://repo.spring.io）。这是完全可以理解的，但对这些限制的适当反应并不是让开发团队陷入手动依赖管理的低效黑暗时代。正确的解决方案是在公司防火墙内建立私有工件存储库。该产品领域的主要竞争者是 JFrog 的 Artifactory 和 Sonatype 的 Nexus。我们强烈建议任何仍被迫进行手动依赖性管理的开发团队游说其架构团队研究这些产品并采用其中之一。对生产力、构建可重复性以及公司有效管理依赖关系的能力的好处是巨大的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
