Tooling api & dependency resolution


(Matt Khan) #1

My build can consume dependencies from a couple of different repositories, for various reasons (that are not really relevant here) it defers the addition of those repositories until a ‘gradle.taskGraph.whenReady’ block. This works fine except for when attempting to use the new gradle support in Intellij 12.1, it results in modules that have a long list of “unresolved dependencies” in the intellij module dependencies screen.

I can see that the tooling api appears to use the same underlying resolution mechanism as the idea plugin which makes me think that it is evaluating the projects but not creating a task graph and hence my repositories are not added hence they can’t be resolved.

Is this correct? Is there a way to tell the project is being evaluated to supply the tooling api rather for running a build?


(Matt Khan) #2

anyone?


(Luke Daley) #3

My build can consume dependencies from a couple of different repositories, for various reasons (that are not really relevant here) it defers the addition of those repositories until a gradle.taskGraph.whenReady block

It is relevant why this is happening. Finding a way not to do this will be the simplest solution.


(Matt Khan) #4

OK thanks. I take it this means a project has no knowledge of the reason why it is being evaluated?


(Matt Khan) #5

the reason this is happening is along the same lines to the Q asked in this question to which you replied

The most common way to do this is to use the gradle.taskGraph.whenReady hook

Depending on what the build is for, it needs to add 1 or more of 3 repositories and these have to be added in the “right” order otherwise I may resolve to the wrong version of a given library. I would need to be able to programatically filter out a subset of the resolved dependencies when it is deciding which version is the right one to resolve this, i.e. gradle would need to support the equivalent of a custom latest strategy (in ivy terms).


(Luke Daley) #6

Ok, I think I understand the problem now. This is a bit of a tricky problem.

I wouldn’t base your “mode” (e.g. final release, milestone etc.) on the presence of a task. In practice this just doesn’t work (I know there are some examples out there that advocate this). You need to base it on something that is determined early in the lifecycle.

Right now, the simplest way is to use the presence of project properties. And in your case it may be best to set this property via the ‘gradle.properties’ file. The reason for this is that you currently can’t inject properties at invocation time in the IDEA gui.


(Matt Khan) #7

OK thanks. The mode is based on a property but there is a particular edge case where the the presence of our release task can change which repos it needs. I’ll have to rethink how this is done to avoid needing to know the task.


(Peter Niederwieser) #8

You can check for the presence of the release task name in the issued Gradle command (e.g. ‘gradle.startParameter.taskNames.contains(“release”)’), if that’s good enough.