Dynamic configuration fails with 2.0-rc

In my multiproject if defined in the subprojects definition a “provided” configuration.

configurations {
   provided
}

With the subproject’s build.gradle I defined the dependency like this:

dependencies {
 (....)
        if (custWithDCTM66) {
  provided (lib_dfc.dfc_66, lib_dfc.ctsTransform_66)
  testCompile lib_dfc.dfc_66
 }
 else {
  provided (lib_dfc.dfc_53,lib_dfc.ctsTransform_53)
  testCompile lib_dfc.dfc_53
 }
}

The symbol “custWithDCTM66” is defined as an ext property; it’s value is set by evaluating the command line parameter “-Pcustomer=xxxx”. This worked fine with Gradle 1.x, but now with 2.0-rc1 it fails hard: “You can’t change a configuration which is not in unresolved state!”

So my question is: what pattern should be used with Gradle 2.0 to handle the situation when the actual compile dependencies should be dynamically resolved using the value of a command line parameter?

This code looks fine. The problem is likely somewhere else (e.g. someone might be consuming the configuration in the configuration phase rather than the execution phase), and I’m not sure if it’s really a 2.0 problem (e.g. it could be a problem with the build that for some reason only surfaces in 2.0).

Is there any chance to detect such a problem in Gradle 1.x by warning oder debug messages?

More recent Gradle 1.x versions will fail hard in exactly the same way if a configuration is changed after resolving it. That’s why I said that it might be some sort of coincidence that you only have this problem with 2.0-rc-1. Or perhaps you upgraded from an older Gradle version which didn’t check for this kind of problem.

This issue commonly occurs when you’re using a standard pattern merging the provided configuration into a generated IDE file. Take a look at GRADLE-3101 and http://forums.gradle.org/gradle/topics/gradle_2_0_rc_1_is_now_available_for_testing and see if that describes the issue you’re seeing.

Thanks for the hints. I had some configuration definitions based on the “+=” operator. After changeing the statements by wrapping configurations into a collection as in

plusConfigurations += [configurations.provided]

the error didn’t show anymmore.