BOM is not defining the OkHttp version

[bcmedeiros]

Describe the bug

I'm currently using a few AWS Kotlin SDK modules with the current setup:

<project>
   <dependencyManagement>
        <dependencies>
            <!-- AWS -->
            <dependency>
                <groupId>aws.sdk.kotlin</groupId>
                <artifactId>bom</artifactId>
                <version>1.3.112</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
   </dependencyManagement>
    ...
    <dependencies>
        <!-- AWS -->
        <dependency>
            <groupId>aws.sdk.kotlin</groupId>
            <artifactId>cognitoidentityprovider-jvm</artifactId>
        </dependency>
    </dependencies>
</project>

The issue is, even though I'm importing the aws.sdk.kotlin:bom BOM, I end up with OkHttp 4.12 in my classpath as defined by another BOM I'm inheriting from (Spring Boot), rather than the required 5.0.0-alpha-4, which is the required one.

This causes all sorts of issues in my app, the simplest one to reproduce being the one below:

java.lang.NoClassDefFoundError: okhttp3/ConnectionListener
	at aws.smithy.kotlin.runtime.http.engine.okhttp.OkHttpEngineKt.buildClientWithConnectionListener(OkHttpEngine.kt:165)
	at aws.smithy.kotlin.runtime.http.engine.okhttp.OkHttpEngineKt.access$buildClientWithConnectionListener(OkHttpEngine.kt:1)
	at aws.smithy.kotlin.runtime.http.engine.okhttp.OkHttpEngine.<init>(OkHttpEngine.kt:48)
	at aws.smithy.kotlin.runtime.http.engine.okhttp.OkHttpEngine$Companion.invoke(OkHttpEngine.kt:41)
	at aws.smithy.kotlin.runtime.http.engine.DefaultHttpEngineJVMKt.newDefaultHttpEngine(DefaultHttpEngineJVM.kt:14)
	at aws.smithy.kotlin.runtime.http.engine.DefaultHttpEngineKt.DefaultHttpEngine(DefaultHttpEngine.kt:24)
	at aws.smithy.kotlin.runtime.http.engine.HttpEngineConfigImpl$BuilderImpl$engineConstructor$1.invoke(HttpEngineConfigImpl.kt:20)
	at aws.smithy.kotlin.runtime.http.engine.HttpEngineConfigImpl$BuilderImpl$engineConstructor$1.invoke(HttpEngineConfigImpl.kt:20)
	at aws.smithy.kotlin.runtime.http.engine.HttpEngineConfigImpl$BuilderImpl.engineSupplier$lambda$2(HttpEngineConfigImpl.kt:21)
	at aws.smithy.kotlin.runtime.http.engine.HttpEngineConfigImpl$BuilderImpl.buildHttpEngineConfig(HttpEngineConfigImpl.kt:77)
	at aws.sdk.kotlin.services.cognitoidentityprovider.CognitoIdentityProviderClient$Config$Builder.buildHttpEngineConfig(CognitoIdentityProviderClient.kt)

If I include the OkHttp BOM as follows directly in my file, then the problem is fixed:

            <dependency>
                <groupId>com.squareup.okhttp3</groupId>
                <artifactId>okhttp-bom</artifactId>
                <version>5.0.0-alpha.14</version> <!-- AWS Kotlin SDK needs 5.x, and there are no other users of OkHttp, so overriding Spring's default -->
                <type>pom</type>
                <scope>import</scope>
            </dependency>

Regression Issue

• Select this option if this issue appears to be a regression.

Expected behavior

Declaring the aws.sdk.kotlin:bom with the correct precedence over other BOMs being imported should be enough to have all the dependencies AWS Kotlin SDK needs to run.

Current behavior

SDK fails when making any HTTP calls because the OkHttp version needed is not declared in the BOM.

Steps to Reproduce

1. Create a Spring Boot app with version 3.3.7
2. Add the BOM in the description to de dependency management section and
3. Any AWS SDK module that needs HTTP access to the dependency section
4. Write some code to use the SDK module
5. Run your app

Possible Solution

I think the aws.sdk.kotlin:bom artifact should declare a dependencyManagement entry with the following import, so people are more likely to get the correct version or at least see a conflict showing up when analyzing the issue.

            <dependency>
                <groupId>com.squareup.okhttp3</groupId>
                <artifactId>okhttp-bom</artifactId>
                <version>5.0.0-alpha.14</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

Context

No response

AWS SDK for Kotlin version

1.3.112

Platform (JVM/JS/Native)

JVM

Operating system and version

MacOS 15.2

[cloudshiftchris]

Good find. It looks like we have the same issue, needing to pull in okhttp bom to address it.

The Aws SDK bom should not only align versions between its modules but provide minimum versions for transitive deps.

[ianbotsf]

The Aws SDK bom should not only align versions between its modules but provide minimum versions for transitive deps.

Can you provide some examples of other libraries which include transitive dependencies in their published BOMs? I've looked at published BOMs for Ktor, http4k, Exposed, OkHttp, Jackson, and Spring Framework—all of which seem to include only their own modules and not 3P dependencies.

[cloudshiftchris]

Here’s where Jackson Bom defines external deps: https://github.com/FasterXML/jackson-bom/blob/2.19/base/pom.xml Not a great example - limited external deps. AFK atm will track down other examples later.

…

On Wed, Feb 5, 2025 at 2:44 PM Ian Botsford ***@***.***> wrote: The Aws SDK bom should not only align versions between its modules but provide minimum versions for transitive deps. Can you provide some examples of other libraries which include transitive dependencies in their published BOMs? I've looked at published BOMs for Ktor <https://repo1.maven.org/maven2/io/ktor/ktor-bom/3.0.3/ktor-bom-3.0.3.pom>, http4k <https://repo1.maven.org/maven2/org/http4k/http4k-bom/5.46.0.0/http4k-bom-5.46.0.0.pom>, Exposed <https://repo1.maven.org/maven2/org/jetbrains/exposed/exposed-bom/0.59.0/exposed-bom-0.59.0.pom>, OkHttp <https://repo1.maven.org/maven2/com/squareup/okhttp3/okhttp-bom/5.0.0-alpha.14/okhttp-bom-5.0.0-alpha.14.pom>, Jackson <https://repo1.maven.org/maven2/com/fasterxml/jackson/jackson-bom/2.18.2/jackson-bom-2.18.2.pom>, and Spring Framework <https://repo1.maven.org/maven2/org/springframework/spring-framework-bom/7.0.0-M1/spring-framework-bom-7.0.0-M1.pom>—all of which seem to include only their own modules and not 3P dependencies. — Reply to this email directly, view it on GitHub <#1508 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR5RI767IP4IUHSYUQKZZD32OKH4DAVCNFSM6AAAAABVSBIX5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZYGIYDGNRQGE> . You are receiving this because you commented.Message ID: ***@***.***>

[bcmedeiros]

Spring Boot definitely includes many 3rd-party dependencies, but one could argue that it is a special one. I'll have a look and see if I can find other examples, or think about a different approach.

Even if we don't go down this path, it's pretty bad to have the Kotlin AWS SDK not working out-of-the-box on a brand new Spring Boot project.

[cloudshiftchris]

It is the stated purpose of a BOM to define the minimum requirements - for your own modules released at the same time that results in version alignment; for other deps that results in minimum versions required for this module to work. Something like an okhttp dep is a stereotypical case of a bom entry to specify the minimum version required by this module. I say “minimum” above as conflict resolution could perhaps bump to a higher version.

…

On Wed, Feb 5, 2025 at 3:04 PM Bruno Medeiros ***@***.***> wrote: Spring Boot definitely includes many 3rd-party dependencies, but one could argue that it is a special one. I'll have a look and see if I can find other examples, or think about a different approach. Even if we don't go down this path, it's pretty bad to have the Kotlin AWS SDK not working out-of-the-box on a brand new Spring Boot project. — Reply to this email directly, view it on GitHub <#1508 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR5RI7ZGMZ3WDUSRR6RX6XT2OKKGDAVCNFSM6AAAAABVSBIX5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZYGIZDSMZXGE> . You are receiving this because you commented.Message ID: ***@***.***>

[ianbotsf]

@cloudshiftchris you wrote:

Here’s where Jackson Bom defines external deps:
https://github.com/FasterXML/jackson-bom/blob/2.19/base/pom.xml

That's Jackson's internal BOM used for building its various components. It's not the published BOM for use by consumers. There's a note in the description about this:

NOTE: NOT to be used by components outside of Jackson: application code should only rely on jackson-bom

Jackson's published BOM only lists Jackson components and not 3P dependencies.

Can you provide any other examples of published BOMs intended for use by consumers which include transitive dependencies?

[ianbotsf]

@bcmedeiros, I agree with you on both of these points:

Spring Boot definitely includes many 3rd-party dependencies, but one could argue that it is a special one. I'll have a look and see if I can find other examples, or think about a different approach.

Even if we don't go down this path, it's pretty bad to have the Kotlin AWS SDK not working out-of-the-box on a brand new Spring Boot project.

Yes, Spring Boot is a special case because it defines a platform from which to build your application. It's not a "regular" library-style dependency and so its POM isn't prototypical of library-style published BOMs (e.g., the SDK's BOM).

Also yes, it's not great that the SDK doesn't work out of the box with Spring Boot. I'd really like to close that gap without misusing the BOM mechanism. If you have ideas for another approach, please let us know!

[github-actions]

It looks like this issue has not been active for more than 5 days. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please add a comment to prevent automatic closure, or if the issue is already closed please feel free to reopen it.

[bcmedeiros]

I have had no good idea on how to tackle this. @ianbotsf should we at least reopen this as a documentation issue, so the docs could mention something around "make sure you don't have any other dependencies in your project interfering with this SDK's dependencies such as OkHttp etc?

[ianbotsf]

Our Troubleshooting FAQs already discuss how to resolve dependency conflicts and specifically mention OkHttp. If there are additional docs we can add which will clarify how to consume the SDK and its transitive dependencies then of course we'd love to do so.

That said, "make sure you don't have any other dependencies in your project interfering with this SDK's dependencies such as OkHttp" sounds like general advice for any dependency—not just the AWS SDK and OkHttp. Is there anything unique about the SDK and/or OkHttp which would warrant a special mention?

[bcmedeiros]

That said, "make sure you don't have any other dependencies in your project interfering with this SDK's dependencies such as OkHttp" sounds like general advice for any dependency—not just the AWS SDK and OkHttp. Is there anything unique about the SDK and/or OkHttp which would warrant a special mention?

Yes, I think there is. AWS Kotlin SDK has a bit of a sophisticated dependency tree with the SDK depending on Smithy which depends on whatever HTTP library that is using, and I think most dependencies you add to a project are more "self-contained", and you expect them to "just work", especially if you have added its BOM.

Again, the SDK just fails in a brand new Spring Boot project today. And it's not just Spring, anyone using maven is likely to have some issues because maven prioritise dependencies closer to the root pom being resolved when there are version conflicts, and OkHttp is 2 levels deep IIRC. Anyone using libraries declaring a OkHttp earlier in the list of dependencies, or as a direct dependency instead of an indirect one, is subject to having issues.

In summary, @ianbotsf, IMV the http library being used is such a critical dependency to be left "unmanaged" like this. I agree that adding it to the BOM is not ideal, but overall I think we should to send a stronger message to the user that they need to pay attention to their HTTP library setup as it's not strongly managed by the SDK.

[MaxWinther]

Had the same problem with SpringBoot, which obviously includes some earlier version of OkHttp, forcing a downgrade of the required version

`+--- com.squareup.okhttp3:okhttp:5.0.0-alpha.14 -> 4.10.0

Had to out comment stuff in my gradle file until realising it was that was the rootcause.
`
I solved it by explicitly forcing the required version of OkHttp

implementation("com.squareup.okhttp3:okhttp:5.0.0-alpha.14")

Hopefully this does not have any side effects.

I am not the only one using SpringBoot so I would have been nice if this issue was mentioned in the trouble shooting guide mentioned by @ianbotsf

[bcmedeiros]

I would have been nice if this issue was mentioned in the trouble shooting guide mentioned by @ianbotsf

This might be enough to address this issue, since it's hard to pinpoint one particular component that is responsible for this issue.

[ianbotsf]

Agreed, we should improve the troubleshooting guide to reduce confusion and speed up dependency conflict resolution. We'll evaluate some updates and get them published.