[Feature Request] Support wildcard for configurations

[simonhauck]

Background For large multi module projects that contain multiple languages, resources and generated code there could be a lot of custom configurations that are created for example by val someConfig: Configuration by configurations.creating {} in a build.gradle.kts.

Current behavior

Right now, (at least from my understanding) each configuration must be named explicitly.

Feature request It would be great, if we could specify the modules to consider as a regex or just a wildcard, e.g.

moduleGraphAssert {
    configurations =  setOf("*")
}

What are your thoughts on that?

From a quick scanning of the code it seems that this file would require changes in listAllDependencies function.

[jraska]

Hey,

This should be quite simple to implement and it would be a non-breaking change as if everything would be taken as regex the default of "implementation", "api" would work as simple regex.

The question would be if it is a required feature and if we introduce regex into something which could rather be an explicit list? Can you perhaps share the list of configurations you consider too long to have such feature?

Thanks

[simonhauck]

In our project we have quite a few configuration names. For example we generate license packages, api-clients, static frontend resources and copy zip files as resources in our projects. So some modules do not generate a jar or are explicitly copied to certain locations. So to answer your question: We have currently in our project something like "licenses, allLicenses, staticFrontendResources, externalDocuments, resources, translations, assembly (which more or less packages the application)"

I initially opened this issue, because it feels weird to specify all these configuration names in the top level project, but they are to some extend in my opinion implementation details of the separate sub modules . If someone would rename a configuration the check specified in the parent build gradle will no longer work/detect the module reference. And if a new configuration name is added, the person will most likely not remember to add it as well in the parent module.

As you mentioned, it is of course possible specify all these names as a list. My concern is more related to the susceptibility to errors in new modules / changed modules.

[jraska]

Hey, I finally got into it and looked how this coudl be implemented.

Wouldn't be hard, we would end up with for loop on Regex matchers instead of contains here.

After thinking about it I think I want to favor explicit list of configurations rather then regex for those. I'm closing the issue, Thanks for raising it!

Please if there will be more people requesting this feature, comment here or add 👍 to the original comment. Thanks!