Created gradle configurations aren't correctly configured

[timocov]

According to official gradle docs https://docs.gradle.org/current/userguide/declaring_configurations.html#sec:configuration-flags-roles:

Out of canBeResolved, canBeConsumed and canBeDeclared flags "Configurations should only have one of these flags enabled.". When configurations get created in

smithy-gradle-plugin/smithy-base/src/main/java/software/amazon/smithy/gradle/SmithyBasePlugin.java

Lines 123 to 128 in a770f94

	Configuration smithyBuildConfig = configurations.maybeCreate(
	SmithyUtils.getSmithyBuildConfigurationName(sourceSet));
	smithyBuildConfig.setVisible(false);
	smithyBuildConfig.setTransitive(true);
	smithyBuildConfig.extendsFrom(configurations.getByName(compileOnlyConfigurationName));
	smithyBuildConfig.setDescription("Build-time smithy dependencies for " + sourceSet + ".");

they don't have these flags configured, which means that by default they have all 3 flags set to true (according the gradle's source code).

It feels like smithyBuild configurations should be only marked as canBeResolved and all other flags should be set to false?

[timocov]

I'm happy to contribute if you're happy with the proposal (with the caveat it seems that it might bump the min supported gradle version to 8.3, but considering that you're building against 8.14 already it shouldn't be a problem?).

[JordonPhillips]

I started looking at this, but got side-tracked when I saw we weren't actually running integ tests on 8.2. Now we actually do that, as well as running on the wrapper version and current version.

As for which one to go with, it's a bit tricky. The gradle docs are a bit frustrating to understand, but as I understand it the roles are:

• declarable - A set of named dependencies, e.g. java's implementation.
• resolvable - A set of actual files that get resolved into something like a classpath, e.g. java's compileClasspath.
• consumable - To be honest I still don't really understand what this for. I certainly don't think we need it.

The configurations we have now seem to operate both as resolvable and declarable, but I think declarable is the main role. We might have to split the functionality up, similar to how implementation and runtimeClasspath are split in java. So they're still linked and people won't break when we update, but gradle will have the isolation it wants.

Oh and we don't need to bump the minimum supported version so long as we use the mutable role setters rather than the factory methods that were added later.

[timocov]

Hm, makes sense, I wonder if it should be a couple of distinct configurations:

• smithyCli (declarable; not sure if it gets created right now, but current behaviour might be alright already)
• smithyBuild (declarable; shouldn't inherit anything, but maybe compileOnly?) - for anything related to smithy build process itself (plugins, linters, validators, etc). Potentially some explicitly added models from smithyBuildModel should go here as well (e.g. it load validators, etc).
• smithyBuildModel (declarable; inherits implementation) - for explicitly adding models to the build, but not necessarily adding them to runtime classpath of the project. e.g. if the model is simple and just contains *.smithy files, this can help not adding unnecessary jars to the runtime classpath by not declaring them in implementation/api instead. but if you already added them there - it still will work without a breaking change.
• smithyBuildClasspath (resolvable; gets jars from smithyBuild configuration and probably smithyCli)
• smithyBuildLibsClasspath (not sure about name; resolvable; gets jars from smithyBuildModel configuration, similarly to smithyBuildClasspath)

Not sure if any of it makes sense, but I was just thinking in the light of #162 - adding models with just smithy files to implementation somewhat bloats your classpath (by amount of files at least, but also I don't think many users actually need smithy model files/projections in runtime in 99% cases) and not always desired. Sometimes it can also bring things like "validators" to runtime classpath which won't be running there but just sitting there because the model defined some validation rules along with it which it would want to run during model processing/build time, but not during target runtime (e.g. a service, program, etc).

What do you think @JordonPhillips?