Artifacts and Repositories

An artifact is usually represented in the form of two files:

• The actual content, such as a JAR
• A metadata file, paired with the JAR, that has information about “transitive dependencies” (i.e., the other artifacts that this artifact depends upon)

Artifacts are housed in artifact repositories. Those repositories not only contain the artifacts, but they organize the artifacts for easy access. This includes organizing them by version, so you can request a specific version of an artifact and get it, instead of an older (or possibly newer) version of that same artifact.

Some artifact repositories are public. A typical Android project will use two such repositories:

• JCenter, a popular place for open source artifacts
• Google’s repository, for things like the Android Gradle Plugin

There are other general-purpose artifact repositories, such as Maven Central or jitpack.io. And there can be private repositories, such as ones used by organizations for their own private artifacts, used by their private projects.

So, we have dependencies like these:

dependencies {

  implementation 'androidx.core:core-ktx:1.6.0'
  implementation 'androidx.appcompat:appcompat:1.3.1'
  implementation 'com.google.android.material:material:1.4.0'
  implementation 'androidx.constraintlayout:constraintlayout:2.1.0'
  testImplementation 'junit:junit:4.+'
  androidTestImplementation 'androidx.test.ext:junit:1.1.3'
  androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'
}

For those, Gradle checks with our registered repositories and says “hey, do you have this particular artifact?”. This is based on the group (e.g., org.jetbrains.kotlin), the artifact ID (e.g., kotlin-stdlib), and the desired artifact version. If a match is found, Gradle downloads it and caches it for later use. If no match is found, you get a build error pointing out the difficulty.