An artifact repository is a server whose job is to store and serve the built outputs of software projects, called artifacts. For Java these artifacts are typically JAR files; for other ecosystems they might be wheels, gems, or tarballs. The defining idea is that a build tool can ask the repository for a specific package by name and version, and the repository hands back exactly that file along with metadata describing it.
Apache Maven’s documentation describes its Central Repository as serving two roles: it provides “dependencies for their own builds” to users, and it lets projects publish “releases to be added to the central repository.” This two-sided design, a place to both publish and consume, is what makes the repository the hub of a dependency ecosystem. A developer declares a dependency once, and the build tool retrieves it and everything it needs from the repository automatically.
Sonatype’s documentation for Maven Central makes the consumption side explicit: “The Central Repository is the default repository for Apache Maven, SBT and other build systems.” Because the repository is the default, most builds resolve their dependencies from it without any extra configuration, which is what allows a one-line dependency declaration to pull in a working library.
Artifact repositories come in public and private forms. Public ones like Maven Central or the npm registry serve the whole community; private ones (Artifactory, Nexus, and similar) let an organization host its own internal artifacts and proxy public ones. In both cases the contract is the same: store named, versioned packages and serve them reliably so that builds are repeatable.