Gradle: What Is The Default Configuration and How Do I Change It

When using the gradle java plugin the 'default' configuration extendsFrom 'runtime', 'runtimeOnly', 'implementation'

If you do not use the java plugin then you can define it yourself like this

configurations {
    "default"
}

The java plugin sets up the default configuration here: https://github.com/gradle/gradle/blob/85d30969f4672bb2739550b4de784910a6810b7a/subprojects/plugins/src/main/java/org/gradle/api/plugins/JavaPlugin.java#L437

The documentation is not that good in this area.

An example of "serving" a default artifact from a composite build. The example creates a subproject that refers to a dependency in another project. This can be nessesary when working with composite builds, as only the "default" group can be depended upon.

We use this to take many jars from a single project and serve it as different dependencies when referencing the project as a composite build.

apply plugin: 'base'

configurations {
    depend
}

dependencies {
    depend project(path: ':', configuration: 'ConfWithArtifact')
}

artifacts {
    "default" (file: configurations.depend.singleFile) {
        builtBy(configurations.depend)
    }
}

Unless your build is publishing Ivy modules, the default configuration is mainly relevant when dealing with project dependencies in a multi-project build. Given a multi-project build with projects A and B, if A declares a project dependency on B without explicitly naming a configuration (e.g. dependencies { compile project(":B") }, A (more precisely A's compile configuration) will depend on project B's default configuration. In other words, dependencies { compile project(":B") } is a shortcut for dependencies { compile project(path: ":B", configuration: "default") }.

The default configuration extends from the runtime configuration, which means that it contains all the dependencies and artifacts of the runtime configuration, and potentially more. You can add dependencies and artifacts in the usual way (using a dependencies/artifacts block in B's build script). Alternatively, B could declare a custom configuration, and A could depend on that by explicitly naming that configuration (e.g. dependencies { compile project(path: ":B", configuration: "myCustomConfig") }.