thought maybe I could create a dependency constraint for all valid matching configurations. Tried this, but it has an error (also tried using a string with

.create

same error)

val jbossLoggingConstraint = dependencies.constraints.create(libs.jboss.logging)

configurations.matching {
  !setOf(
    "archives",
    "default",
  ).contains(it.name) && !it.name.contains("Elements") && !it.name.endsWith("Classpath")
}
  .configureEach {
    this.dependencyConstraints.add(jbossLoggingConstraint)
  }

* Where:
Build file '/home/xeno/IdeaProjects/spring-app-commons/module/app-core/build.gradle.kts' line: 6

* What went wrong:
An exception occurred applying plugin request [id: 'our.javalibrary']
> Failed to apply plugin 'our.bom'.
   > Cannot convert the provided notation to an object of type DependencyConstraint: map(valueof(DependencyValueSource)).
     The following types/formats are supported:
       - Instances of DependencyConstraint.
       - String or CharSequence values, for example 'org.gradle:gradle-core:1.0'.
       - Maps, for example [group: 'org.gradle', name: 'gradle-core', version: '1.0'].
       - Projects, for example project(':some:project:path').
       - Instances of ProjectDependency.
     
     Comprehensive documentation on dependency notations is available in DSL reference for DependencyConstraintHandler type.

I think you need to call get() on libs.jboss.logging. Version catalog accessors usually return a provider and a provider is not in the list of accepted notations.

there actually is a version that accepts a provider, tried that too, but like I said, also tried the stringy version

How about

configurations.matching {
    !setOf(
        "archives",
        "default",
    ).contains(it.name) && !it.name.contains("Elements") && !it.name.endsWith("Classpath")
}
    .configureEach {
        dependencies {
            constraints {
                this@configureEach(libs.jboss.logging)
            }
        }
    }

?

looks like that works. btw, is there a more efficient way to do the matching part? is there something other than matching name that I can do?

Well, maybe you should not create a new set to use contains for each and every matched configuration. Either pull the set creation out of the

matching

or just use two

==

checks and an

&&

instead. Other than that, I don't know whether there is a better way, as I don't know what your goal is. If your goal is, to match all configurations that are not named

archives

, not named

default

, not name ends with

Classpath

, and not name contains

Elements

, well, then that is your check. I just don't see much logic in that condition, but if that is your use-case, ... 🙂

those caused errors 😉 it wouldn't let me operate on configurations matching those names 😉

As I said, using a set is also find, but by having it within

matching

you create a new set for each and ever tested configuration.

honestly, doesn't look like that error comes up with the way you write the code, so, pretty certain I can just remove that 😉