Transitivity for a custom ('provided') dependency configuration


(Max Grigorev) #1

Hey everyone.

I’m trying to set up a ‘provided’ configuration which will have a property of transitivity. As in “if P is a provided dependency of A and B depends on A then P is also a provided dependency of B”.

I set up a new ‘provided’ configuration as usual:

configurations {

provided } sourceSets {

main { compileClasspath += configurations.provided } } dependencies {

provided ‘…’ }

It works like a charm for specifying a direct provided dependency (the one for A). But I’m really struggling with adding transitivity. I tried to figure out a way to just append the contents of the dependencies’ provided configurations to a given project’s provided config, but seems my knowledge of Gradle internals is not sufficient at this point.

Any hints? :slight_smile: Is it possible within the limits of the current API, without modifying the Gradle’s code? And is it possible to modify the dependency graph dynamically with appropriate effect at all?

Thanks a lot!


(Max Grigorev) #2

Hm, seems like no one knows a way. Could someone just answer my latter question please?

Is it possible to modify the dependency graph dynamically with appropriate effect at all?


(Peter Niederwieser) #3

To get transitivity, you can make the ‘compile’ configuration extend the ‘provided’ configuration (instead of adding the latter to ‘compileClasspath’). To answer your second question, you’d have to elaborate on what exactly you mean by “modify the dependency graph dynamically with appropriate effect”.


(Max Grigorev) #4

To get transitivity, you can make the compile configuration extend the provided configuration (instead of adding the latter to compileClasspath)

Hm, let me see if I understand you correctly. You are suggesting that I do:

configurations {

provided

compile {

extendsFrom provided

}

}

But that, to my (lacking) knowledge, would get the provided dependencies to show up in both compile and runtime configurations - and I use the latter to build a fat jar. The need for a separate configuration arises specifically because I want to keep the provided dependencies out of the runtime config.

Am I making sense?

To answer your second question, you’d have to elaborate on what exactly you mean by “modify the dependency graph dynamically with appropriate effect”.

Let me try. Is there a way to put some code in the project’s build.gradle, that will alter the dependency graph after it has already been built by the internal gradle logic? Like

afterEval(project) {

project.configurations.compile.add(“some new dependency”)

// or

project.configurations.compile.remove(“some dependency”)

}

Apologies for not being clear before.

Really appreciate your help, Peter!


(Max Grigorev) #5

So - no ideas, anyone?


(Peter Niederwieser) #6

You can add dependencies to a configuration until it has been resolved. That is, until someone has requested its files.

A dependency between modules A and B is really a dependency between configuration X of A and configuration Y of B. X always has to be specified. If Y isn’t specified, it defaults to ‘default’. Y can be specified both for project dependencies and for external dependencies. For example:

dependencies {

provided project(path: “:other”, configuration: “provided”)

provided group: “foo”, name: “bar”, version: “1.0”, configuration: “provided” }