slachiewicz opened a new issue, #125:
URL: https://github.com/apache/maven-shared-io/issues/125
`maven-shared-io` depends on both Wagon and `maven-compat`. These are not
two separate cleanups —
they are the same change, because the class that needs Wagon obtains it from
a `maven-compat` type.
With `maven-compat` gone in Maven 4, this is a blocker rather than hygiene.
### Current state
Resolved by `dependency:list` on `3.1.0-SNAPSHOT`:
```
org.apache.maven.wagon:wagon-provider-api:jar:3.5.3:compile
org.apache.maven:maven-compat:jar:3.6.3:provided
```
**Wagon is in the published API**, not just the implementation —
`DownloadManager`:
```java
import org.apache.maven.wagon.events.TransferListener;
File download(String url, List<TransferListener> transferListeners,
MessageHolder messageHolder)
throws DownloadFailedException;
```
**`maven-compat` supplies the Wagon** — `DefaultDownloadManager`:
```java
import org.apache.maven.artifact.manager.WagonManager; // maven-compat
...
wagon = wagonManager.getWagon(sourceUrl.getProtocol());
wagon.connect(repo, wagonManager.getAuthenticationInfo(repo.getId()),
wagonManager.getProxy(sourceUrl.getProtocol()));
```
So `WagonManager` is the source of the `Wagon`, of the authentication info,
and of the proxy.
Dropping `maven-compat` while keeping Wagon would leave nothing able to
construct or configure a
transport; dropping Wagon requires changing a public method signature.
Either direction forces the
other.
A second, independent `maven-compat` user is `ArtifactLocatorStrategy`,
which takes
`org.apache.maven.artifact.repository.ArtifactRepository` in its
constructors and resolves through
the legacy stack.
### Why now
Maven 4 does not ship `maven-compat`. Any consumer of `maven-shared-io` that
reaches
`DefaultDownloadManager` or `ArtifactLocatorStrategy` under Maven 4 fails at
runtime, regardless of
what this project compiles against.
Both halves were raised before and closed as *not planned* in December 2021,
with no rationale
recorded on either:
- #39 — [MSHARED-928] shared-io should not depend on maven-compat
- #48 — [MSHARED-931] Deprecate and remove/replace ArtifactLocatorStrategy
The constraint has changed since those were closed, so they are worth
revisiting rather than
treating as settled.
### This is a major version
`TransferListener` appears in an interface method signature, so any
replacement is a binary- and
source-incompatible change to `DownloadManager`. The realistic shape:
- re-implement downloading on Resolver's `TransporterProvider` /
`Transporter`, as
`maven-build-cache-extension` already does;
- replace `List<TransferListener>` with a neutral progress-callback type
owned by this project, or
drop the overload;
- replace `ArtifactLocatorStrategy`'s legacy resolution with Resolver,
changing its constructors.
That is a `4.0.0`.
### Worth deciding first: rewrite or retire
Before committing to that work, it is worth establishing who still consumes
this. Across the local
checkout of the `apache/maven-*` estate, the only reference to
`maven-shared-io` is a test fixture
pom in `maven-assembly-plugin`
(`src/it/projects/bugs/massembly-324/pom.xml`) — not a real
dependency of any shipped component. The last release was `3.0.0`.
If that survey holds more broadly, retirement may be the better answer than
a major rewrite, and
the retirement path is cheaper to execute than the migration. Either way the
decision should come
before the code.
<sub>Drafted with Claude — please verify</sub>
--
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]
