Support providing settings via Global and ThisBuild

Is your feature request related to a problem? Please describe.

Currently all the settings are rigidly defined at the project level (foo := defaultFoo in projectSettings). This means that the users can only override each of them at the project level - so Global/foo and ThisBuild/foo are ignored. This is inconvenient for multi-project builds, where it makes sense to provide project-wide overrides in local.sbt.

Describe the solution you’d like

Most of the defaults don’t depend on the other project settings (e.g. foo := baseDirectory.value), and don’t use extra scoping (e.g. aggregate in foo) . We should move those to globalSettings as described here. For the other settings we should only provide the default if there’s no previous value:

foo := foo.?.value.getOrElse(defaultFoo)

[albuch]

Thanks for your explanation. In my day to day work I only see rather simple project setups, so I highly value input from a point of view of more complex setups. I suggest to release it like it currently is and address other more special use cases if any come up later. I’ll update the docs for this PR and prepare a v3.0.0 release.

[nigredo-tori]

@albuch, in that quote I was talking about the defaults that are, by their nature, local to a project. In your PR, those are

dependencyCheckOutputDirectory := Some(crossTarget.value),
dependencyCheckScanSet := Seq(baseDirectory.value / "src/main/resources"),

We can’t reduce those to Global settings.

I don’t see the point: the defaults that are currently set are needed because there are no defaults by the underlying core library as they are build system dependend.

I wasn’t arguing about adding new defaults, just about massaging the existing ones.

Overriding a setting on the project level will always have precedence over the default value, that’s how Scope delegation works.

Scope delegation is not involved here. dependencyCheckOutputDirectory settings in the plugin and in build.sbt (on project level) have to use the same scope.

A value from your build.sbt will always have precedence over a default value from sbt-dependency-checks projectSettings.

Probably. I can imagine a situation with user code in a separate AutoPlugin setting dependencyCheckOutputDirectory, but not defining a dependency on DependencyCheckPlugin - in which case the resulting value of dependencyCheckOutputDirectory would depend on the order in which SBT happens to apply the plugins. Though that does sound as an unlikely scenario/use case, so I’m probably overthinking it.

All an all, I’m perfectly happy with just moving the “simple” defaults to Global, as you have done in your PR.