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).
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.
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