[ci] test native Maven transport (remove wagon workaround)

[joewiz]

Summary

Test branch to validate removing the stale maven.resolver.transport=wagon setting from global MAVEN_OPTS and switching to Maven Resolver's native HTTP transport with explicit timeout configuration.

Context

The maven.resolver.transport=wagon flag was added in March 2023 (commit 77592f63f5, message "testing") as a workaround for early Maven 3.9.0 instability. mvnd 1.0.3 now bundles Maven 3.9.11, where native transport is stable. The flag is stale and was identified as part of investigating CI hang issues (see #6186).

Two unreliable repos cause CI hangs with wagon:

• repo.exist-db.org — accepts TCP, then sends FIN → CLOSE_WAIT; wagon waits indefinitely
• repo.evolvedbinary.com — returns HTTP 504 from CI runners; completely unreachable

Changes

• Remove maven.resolver.transport=wagon from global MAVEN_OPTS — lets mvnd use native transport (Maven 3.9.11 default)
• Add Aether native transport timeout flags via step-level MAVEN_OPTS on Maven Build: aether.connector.basic.connectTimeout=10000, aether.connector.basic.requestTimeout=30000 (10s connect, 30s read)
• Add --offline to license check — the develop Maven cache always has all required artifacts; eliminates 7+ min timeouts from unreachable repos

What to watch

If native transport works correctly, Maven Build should complete on all platforms without wagon-induced hangs. If there are artifact resolution failures that wagon previously masked, they'll surface as explicit download errors rather than silent hangs.

Related: #6186

[duncdrum]

I think this PR is on the right track. We are masking download progress on ci as it's massively polluting the logs. I would remove the flags from the build invocations which are timing out here.

In theory we should never require the eb repo to be available. Maven central and exist-db.org as fallback should handle all dependencies. Caveat xqts snapshots awaiting a v7 release, only available from github.

We need to figure out why both mvn central and exist-db.org are not doing it.

[line-o]

The test workflow file has an issue and did not run

(Line: 62, Col: 19): Unrecognized named-value: 'env'. Located at position 1 within expression: env.MAV

https://github.com/eXist-db/exist/actions/runs/24222747978

[joewiz]

[This response was co-authored with Claude Code. -Joe]

@line-o Thanks for catching that! You're right — ${{ env.MAVEN_OPTS }} is not valid in a job-level env block (the env context isn't available there). It IS valid at step level though, so I've reworked it: each step now has its own env block that extends the global MAVEN_OPTS via ${{ env.MAVEN_OPTS }}. The run: commands are now clean — goals and step-unique flags only. CI is running now to verify.

[line-o]

@joewiz Is it expected that all tests fail with this PR applied?

[joewiz]

[This response was co-authored with Claude Code. -Joe]

The latest CI run shows all test jobs failing by timeout rather than actual test failures — unit tests passed (BUILD SUCCESS) but the subsequent Javadoc step ran for 61 minutes before hitting the 75-minute job ceiling; all integration test runs hit the 45-minute step timeout. For comparison, the last clean develop run (April 2) had integration tests completing in 15–31 minutes and unit in 17 minutes, so the runners appear to be running 2–4× slower today. The first run on this PR (before the DRY cleanup) was all green, so I don't believe the YAML changes are at fault.

[duncdrum]

Our PRs had simultaneous CI runs. From what I understand this means we share resources, so I ll restart some jobs to see if they are still slow.

[joewiz]

All checks have passed! If this looks good and it's merged, I'll rebase my PRs so we can hopefully see tests passing again. Thanks!