This message was deleted.

I would expect

buildscript {
    dependencies {
        constraints {
            classpath(...)

to work

It should if done properly. Also see https://blog.gradle.org/log4j-vulnerability

@Vampire - not sure if I am missing something, but doing

constraints

did not work on dependencies pulled in by the plugins (works fine for normal dependencies, but if it is coming from a plugin, it seems to be ignored

As you can see in the blog post, it works fine, so maybe you should provide an MCVE 🙂

weird, we use this for managing transitive vulnerable dependencies in our project, and that works fine, but when I tried to do this to a dependency pulled in via a plugin it seems to have ignored it

if you want it in

settings.gradle

, try

gradle.beforeProject {
    buildScript {
        ...

That wouldn't help much for settings plugins though. But simply using

buildscript { ... }

there should also work

right, you'd need it in the body of the settings script too

Btw. @ephemient are you aware of a difference between

gradle.allprojects { ... }

and

gradle.beforeProject { ... }

when called from a settings script?

I didn't check at what point

allprojects

runs

Should run immediately for all projects already there and on newly added ones as soon as they are added. But I think either way before the actual build scripts come into play if I'm not remembering wrongly.

in any case, these constraints aren't inherited from parent to child so you need to apply to all projects afaik

I am clearly missing something - what is the significance of

buildScript

- I thought this is some legacy statement (a lot of instructions mentioning say to use it only with older gradle) , but I starting to think I am wrong

That is wrong, yes

wouldnt be the first time

You should not use it to add plugins to the classpath and then apply them using the legacy mechanism

also if you have a plugin that doesn't have a proper marker, you have to either add the dependency in buildscript (or add resolution rules to pluginManagement). that works together with the plugins block, it's not a full replacement

ok - I am still a bit confused about constraints for plugin - do I need to do this as :

// in build.gradle
buildScript {
  dependencies {
    constraints {
       ...
    }
  }
}

yes

that works but only for plugins applied in that project (not other subprojects)

of course

buildscript { dependencies { classpath(...) } }

is inherited by child subprojects

For now I just want to get the parent project to work 😄

buildscript { dependencies { classpath(...) } }

is inherited by child subprojects

Only kind of. It is not really inherited. It only works on the classpath of the current build script. This classpath lands on a class loader. This class loader is the parent of the class loader of the child project buildscript class loader. And as class loaders first have to ask their parent for a class before serving it themselves, the one would win. But on the class loader of the child project you could still have the a different version, maybe with vulnerabilities and so on. 🙂

"kind of" sure, it's classloader inheritance and not extending the buildscript configuration but classloaders load from their parent first, so even if you add a different versioned dependency in a child project's buildscript, for any classes that exist in the parent, you'll get that instead of whatever the child requested

You never know what people come up with to use vulnerabilities. The vulnerable jar will be already present and can maybe easily be used by evil-doers. 🤷‍♂️

I wonder if it's in the realm of feasibility for project isolation to break that parent classpath connection and instead use the parent as a "dependency"