Code repository stores the libraries and helps manage the dependencies of the different libraries. In the old times, when Java projects used ANT as a build tool and without the later added Ivy dependency management, the libraries that were needed by a project were downloaded to the source code, usually to the lib library. If a library needed another library, then those were also downloaded and stored manually, and this continued until all the libraries that one of the already downloaded libraries needed were copied to the source code tree.

This was a lot of manual work and, also, the library code was stored in the source code repository in many copies. A compiled library is not source code and has nothing to do in the source code repository. Manual work that can be automated has to be automated. Not because developers are lazy (yes, we are and we have to be) but because manual work is error prone and, thus, expensive.

This was when Apache Ivy was invented and Maven, following ANT, already supported repository management built in. They all stored the libraries structured in directories and supported metadata that described the dependencies to other libraries. Lucky that Gradle did not invent its own code repository. Instead, it supports both Maven and Ivy repositories.

Using the repository, the build tools automatically download the libraries that are needed. In case a library has a new version, then the developer only has to update the version of the needed library in the build configuration and all tasks, including downloading all the new versions of the other libraries that are needed by that version, are done automatically.