slachiewicz opened a new issue, #366:
URL: https://github.com/apache/maven-jxr/issues/366
`maven-jxr-plugin` declares `wagon-provider-api` at compile scope, but uses
Wagon for one thing
only: parsing a URL. Removing it is feasible, and this is the last tie the
plugin has to the
legacy Maven stack.
### Current state
`maven-jxr-plugin/pom.xml`:
```xml
<wagonVersion>3.5.3</wagonVersion>
...
<dependency>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-provider-api</artifactId>
<version>${wagonVersion}</version>
</dependency>
```
There is exactly one import and one use in the whole tree —
`JxrReportUtil.java`:
```java
import org.apache.maven.wagon.repository.Repository; // line 30
...
Repository repository = new Repository(site.getId(), site.getUrl()); //
line 221
if (StringUtils.isEmpty(repository.getBasedir())) {
return repository.getHost();
}
```
Only `getHost()` and `getBasedir()` are ever called. Wagon is a URL parser
here and nothing else —
no transport, no `Wagon` instance, no `WagonManager`.
`dependency:list` confirms
`org.apache.maven.wagon:wagon-provider-api:jar:3.5.3:compile` is the
only Wagon artifact in the resolved tree.
### On maven-compat
This plugin has **no** `maven-compat` dependency — not declared, not
resolved, and no
`org.apache.maven.artifact.manager` / `org.apache.maven.repository.legacy`
imports in the source.
So unlike other components carrying Wagon, there is no coupled compat
removal to do here: Wagon is
the only remaining legacy-stack dependency, and dropping it leaves the
plugin clean.
### Two things that complicate the obvious fix
**1. The code it mirrors no longer exists.** `getStructure` carries this
comment:
```java
// @todo come from site plugin!
// @see o.a.m.p.site.SiteStageMojo#getStructure(MavenProject project,
boolean ignoreMissingSiteUrl)
```
`getStructure` is gone from `maven-site-plugin` — the referenced method is
no longer there. So this
is reimplementing an abandoned staging layout. The value is consumed in one
branch of
`AbstractJxrReport#constructJavadocLocation`, reached only when the
`stagingDirectory` system
property is set. There is no test coverage of `getStructure` at all.
**2. `java.net.URI` is not a drop-in replacement.** `dav:https://…` and
`scm:svn:…` are opaque
URIs, so `URI.getHost()` returns `null` for them. Site URLs in ASF poms do
use `dav:` and `scp:`,
so a naive swap would silently change behaviour on exactly the inputs this
code exists for.
A faithful replacement has to reproduce `PathUtils.host` and
`PathUtils.basedir`, which carry real
special cases:
- `file://` with Windows drive letters, in both `C|` and `C:` forms
- IPv6 hosts with the surrounding brackets stripped
- `user:password@host` userinfo removed from the host
- `scm:` / `scm:svn:` prefixes skipped
- `:` rewritten to `/` in the path (a CVS-ism)
- URL-decoding of the `file:` path
- `"localhost"` returned when no host is present
### Suggested resolution
Because the path is untested, the safe order is:
1. Add characterisation tests for `getStructure` pinning current behaviour
across `scp:`, `dav:`,
`https:`, `file:` (including a Windows drive letter) and a
userinfo-bearing URL, while Wagon is
still on the classpath.
2. Then decide between:
- **port** — a private parser reproducing the `host` + `basedir`
semantics, with the tests
unchanged; or
- **delete** — drop the site-URL-derived structure entirely, on the
grounds that the layout it
targets no longer exists in `maven-site-plugin`.
Option 2b is worth considering first: if nothing produces that staging
layout any more, porting a
parser to feed it preserves a behaviour that may already be wrong.
<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]
