[timocov]

What behavior changes?

There is a chance that a consumer of smithy-java can get modules of different versions (e.g. core:1.6.0 and io:1.8.0) which can cause problems in runtime. There is already a mechanism that fails the startup to avoid such issues (done via version-spi module). But it feels like we can go one step further (at least for Gradle users) and add BOM cross-reference to every published module so that when say you get core:1.6.0 you also automatically get bom:1.6.0, and if you also get io:1.8.0 it will come with bom:1.8.0 and then Gradle will pick bom:1.8.0 and align versions for both used modules.

Why is this change needed?

To reduce number of version mismatches when using clients published with different smithy-java versions and address the issue earlier (than just failing at the startup).

How was this validated?

• Imported project into IntelliJ without any issues
• Running gradle in the project without issues
• pTML works too and each published module contains reference to software.amazon.smithy.java:bom:{currentSmithyJavaVersion}

What should reviewers focus on?

Due to the way smithy-base gradle plugin works, it resolves runtimeClasspath during configuration to detect smithy cli version which causes "cannot modify after observing" error from Gradle. In order to overcome this, I explicitly added smithy-cli dependency to smithyCli configuration with the version being aligned to current smithy version. It doesn't change the version - it is still aligned with the rest of the modules, but just something that might not be obvious (but it is worth nothing that this is something anyone with strict dependency locking has to do anyway, otherwise you will get similar error).

Additional Links

For instance, jackson-core has the same: https://repo1.maven.org/maven2/tools/jackson/core/jackson-core/3.1.0/jackson-core-3.1.0.module (in this case jackson-core references jackson-bom).

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[timocov]

The order of loaded plugins changed, it doesn't feel like a big deal considering that plugins aren't ordered by default, but let me know. (maybe test check should not rely on the order?)