google-cloud-nio: transitive google-cloud-storage dependency causes scope conflicts when used at test scope

[gustavovnicius]

Problem

google-cloud-nio is commonly used at test scope to provide a java.nio.file.FileSystemProvider for gs:// URIs in tests. However, it depends on google-cloud-storage at compile scope, which pulls in ~15 transitive dependencies.

When a project already has google-cloud-storage at compile scope (e.g. via spring-cloud-gcp-starter-storage), adding google-cloud-nio at test scope can cause Maven's "nearest definition wins" rule to silently re-resolve google-cloud-storage and its transitives at test scope. Build tools that strip test-scoped jars from the runtime image (e.g. Jib) then produce containers with missing classes, causing ClassNotFoundException at startup.

The current workaround is to manually exclude google-cloud-storage from google-cloud-nio:

<dependency>
    <groupId>com.google.cloud</groupId>
    <artifactId>google-cloud-nio</artifactId>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>com.google.cloud</groupId>
            <artifactId>google-cloud-storage</artifactId>
        </exclusion>
    </exclusions>
</dependency>

This is fragile and non-obvious. Every consumer hitting this has to independently discover the problem and apply the same fix.

Suggestion

One of:

1. Separate artifact: publish a google-cloud-nio-testing artifact that contains only the FileSystemProvider registration and declares google-cloud-storage as provided or optional. This matches the pattern used by other GCP libraries (e.g. google-cloud-bigtable-emulator-core).

2. Mark google-cloud-storage as optional: in the existing google-cloud-nio POM, declare google-cloud-storage as <optional>true</optional>. Consumers already have it on the classpath at compile scope via their GCS integration. This avoids the transitive scope conflict without a new artifact.