slachiewicz opened a new pull request, #126: URL: https://github.com/apache/maven-shared-io/pull/126
Wagon is used by exactly one package here, `org.apache.maven.shared.io.download`, and that package cannot run without `maven-compat` for the `WagonManager` that hands out providers, proxies and credentials from `settings.xml`. `maven-compat` is already `provided`, so anyone calling `DownloadManager` has always had to declare it themselves. `wagon-provider-api` was the odd one out at compile scope, handing itself to every consumer of the `location`, `logging` and `scan` packages — none of which will ever call a Wagon. It is now optional, so consumers of `DownloadManager` declare it the same way they already declare `maven-compat`. The javadoc on the interface says as much, so anyone who meets a `NoClassDefFoundError` finds the reason at the class they were using. Measured with a throwaway consumer POM: | depends on | inherits | | --- | --- | | `maven-shared-io:3.0.0` | `org.apache.maven.wagon:wagon-provider-api:jar:2.10:compile` | | this build | nothing — no Wagon at any scope | Labelled `breaking` for the release notes: a consumer of the download API that relied on the transitive dependency has to add one declaration. Verified: `mvn clean verify` → 93 tests, 0 failures, including all 22 `DefaultDownloadManagerTest` ones — an optional dependency stays on the module's own compile and test classpath, so only downstream propagation changes. *This change was created with AI assistance.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
