Updating dependencies on configurations

Help/Discuss
1

Hello everyone,

The Griffon project has a Gradle plugin that’s capable of resolving custom BOM files in such a way that additional dependencies are added to well known configurations, such as compile and testCompile. This plugin uses the dependencies.incoming.beforeResolve mechanism and for the time being it works. However since Gradle 2.3 we have seen a warning appear, such as

Changed dependencies of configuration ':kiosk:compile' after it has been included in dependency resolution. This behaviour has been deprecated and is scheduled to be removed in Gradle 3.0. Use 'defaultDependencies' instead of 'beforeResolve' to specify default dependencies for a configuration.
Changed dependencies of parent of configuration ':kiosk:testCompile' after it has been resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 3.0
Changed dependencies of parent of configuration ':kiosk:testRuntime' after it has been resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 3.0
Changed dependencies of parent of configuration ':kiosk:integrationTestCompile' after it has been resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 3.0
Changed dependencies of parent of configuration ':kiosk:runtime' after it has been resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 3.0

We’d like to make our plugin a better citizen with Gradle 2.x and 3.x, so, does anyone know the way to properly handle and update configurations? The plugin adds core dependencies using https://github.com/griffon/griffon/blob/development/subprojects/gradle-griffon-plugin/src/main/groovy/org/codehaus/griffon/gradle/GriffonPlugin.groovy#L235-L329
BOM parsing is performed by https://github.com/griffon/griffon/blob/development/subprojects/gradle-griffon-plugin/src/main/groovy/org/codehaus/griffon/gradle/GriffonPluginResolutionStrategy.groovy

Any hints are greatly appreciated.

2

The problem is that you’re adding dependencies to the :kiosk:compile configuration after the :kiosk:testCompile configuration has been resolved. This means that testCompile will not contain the added dependencies, even though it extends the compile configuration.

This is unlikely to be what you want, and is a fundamental problem with using beforeResolve for supplying additional dependencies, since it doesn’t fire when resolving child configurations. We didn’t change the way it works, but we recently added the warning about it.

To avoid the warning and make this more correct, you’ll need to modify the configuration earlier in the build, rather than relying on beforeResolve. I don’t have any suggestions on the best way to do this, off the top of my head, sorry.

3

Thank you for the info Daz.
Is there another lifecacle phase I can hook into to figure out what can be done? I was able to figure out the beforeResolve option after discussing with Peter N. close to a year ago.

4

Unfortunately, the only obvious place for a plugin to do this sort of work is in project.afterEvaluate. Improving this is one of the key objectives of the upcoming rule-based configuration model.

5

Correct me if I’m wrong but wouldn’t using project.afterEvaluate be too late? All configurations should have been resolved by then, shouldn’t they?

6

Hey Andres,

configurations are not resolved at a particular point in time in gradle. They are resolved when needed. So project.afterEvaluate should be fine if you havn’t used (resolved) any configurations at configuration time.

7

Aha! So if a plugin requires resolution of testCompile configuration and this happens before project.afterEvaluate I’m basically screwed, isn’t it?

8

Hi Andres,

Can you point me to a Gradle project that uses your plugin and produces the warning messages you are seeing? I’d like to set up a test case for your plugin and go from there to find a viable solution.

Cheers,

Ben

9

I recall now that I added a workaround to the problem by resolving dependencies as late as possible. Please see https://github.com/griffon/griffon/issues/155 and https://github.com/griffon/griffon/commit/01015708fef3baf83de1e19b1ff24ecf689232ce

The only configuratio that the custom strategy must resolve right away is the “griffon” configuration.

10

Thanks for the feedback. Correct to assume that this issue doesn’t need anymore action from our end?

11

I think the original problem can be reproduce if dependencies are updated earlier during the build. My workaround simply makes sure BOM dependencies are queried and processed as lat as possible.

I’d prefer if there was a better hook exposed by the Gradle API to modify dependencies before configurations are treated as immutable for performance reasons.

12

Got it. Any chance you can put together a minimal example on GitHub that reproduces the issue you were seeing? It would be much easier for us to extract the use case and the essence of the issue in order to work on an adequate fix.