How to access dependency classifier and extension in gradle build script

Help/Discuss
1

Hi there,

it’s possible to define a dependency like this:

configurations {
deps
}

dependencies {
deps group: ‘my.special.groupid’, name: ‘myapplication’, version: ‘1.0.10’, ext: ‘jar’, classifier: ‘runnable’
}

Now I like to access my dependencies within gradle build script.
Currently I do it like this:

task printDeps() {
configurations.deps.dependencies.each {
println “${it.group} - ${it.name} - ${it.version} - ${it.ext} - ${it.classifier}”
}
}

But now I’m getting
Could not get unknown property ‘classifier’

Without classifier I’m getting
my.special.groupid - myapplication - 1.0.10 - org.gradle.api.internal.plugins.DefaultExtraPropertiesExtension@5716dec8

So please tell me how to set classifier and extension in dependency correctly and
what do I have to do to access classifier and extension of my dependencies within a gradle task?

2

Extensions and classifiers are attributes of a dependency’s artifacts. For each dependency you can call getArtifacts, which will return a set of DependencyArtifact.
Note, getArtifacts is not available for all subinterfaces of Dependency.

For example:

configurations {
    deps
}

dependencies {
    deps group: 'junit', name: 'junit', version: '+', ext: 'jar', classifier: 'sources'
    deps group: 'junit', name: 'junit', version: '+', ext: 'jar'
    deps group: 'junit', name: 'junit', version: '+'
}

task printDeps {
    doLast {
        configurations.deps.dependencies.each { dep ->
            println "${dep.group} - ${dep.name} - ${dep.version}"
            dep.artifacts.each { art ->
                println "    ${art.extension} - ${art.classifier}"
            }
        }
    }
}

Outputs:

:printDeps
junit - junit - +
    jar - sources
junit - junit - +
    jar - null
junit - junit - +

Side question; Do you really want the configured dependencies, or do you want the resolved dependencies? In my example, the configured dependencies have a version of +, but a resolved version would be something like 4.12

3

Awesome.
Thank you very much. This works.

4

It’s ok for my purpose to use the configured deps. But if you know a possibility to access the resolved dependencies I would be interested.

5

Sure, explore configurations.xyz.resolvedConfiguration and configurations.xyz.incoming.resolutionResult.

incoming.resolutionResult can be useful if you don’t want a failure in the resolving of the dependency graph to cause an exception, whereas resolvedConfiguration will cause one. Of special interest here is things that return a DependencyResult (ie. configurations.xyz.incoming.resolutionResult.allDependencies), which are actually returning a ResolvedDependencyResult or UnresolvedDependencyResult. You can then detect the instance type and act upon it as necessary.

6

Some extra notes; As a general best practice, you’ll want to avoid using these during Gradle’s configuration phase. Triggering the resolution of a configuration during the config phase can cause you annoyances and sometimes issues/failures.

  1. Time will be spent resolving the configuration even if it may not be needed. For example, running gradle tasks usually has no need for dependency resolution, so don’t waste time doing it when Gradle configures the project.
    1.1 An extension to #1, a failed dependency resolve during the configuration phase is very frustrating when your trying to use the various reporting tasks (tasks, model, projects, components, etc).
  2. Resolving a configuration before the config phase is complete may result in the configuration’s settings being incomplete at the time of resolution. This can happen when there exists config code after you resolve the configuration (some settings of a configuration will cause a failure if the configuration has already been resolved).

There may be more good reasons not to resolve a configuration during the config phase, but those are my personal top two.

1 Like