Is there a mechanism for a configuration to be “locked”. That is, prevent a configuration from being effected by an upstream build script performing an “all” closure and thereby effecting a configuration that may be in a plugin. In my case I had a build.gradle set transitive to false in an “all” configurations closure. Needless to say this broken my plugin with a ClassDefNotFound exception.
You might want to look into making the configuration non-visible. I am not sure if that will solve your problem. Let me know if that works for you.
Thanks Ben, how does this setting work for a plugin? If a plugin has its internal configuration(s) visibility set to false, can the project applying the plugin see and/or change the configuration?
‘visible’ won’t help here. If a plugin wants to internally use a configuration, it should create a detached configuration with ‘configurations.detachedConfiguration’. Such a configuration isn’t added to the configuration container, and therefore isn’t accessible to anyone else (including ‘configurations.all’ rules).
Thanks Peter! This sounds exactly like what I need.
I am a little surprised that this method does not get more publicity (i.e. a mention in the users guide for this use case, an expanded description in the Javadoc). Seems like a very important method for plugin developers to consider. Any large site with many developers will likely hit the issue of someone doing a configurations.all in their build.gradle that busts various plugins. I am inclined to treat all my plugin configurations as detached unless I explicitly intend the applying build.gradle to manipulate it.
Cheers, Baron
I wouldn’t use detached configurations in this instance. Detached configuration does not give the user any way to influence the resolution.
Baron’s use case (I have the insider info 
is wrapping a built-in checkstyle plugin with his own, specifically configured checkstyle plugin. I think it is really important if tools like checkstyle, jacoco, findbugs, etc expose the configurations they use.