[slachiewicz]

FELIX-6876: the remote OBR goals (bundle:deploy with remoteOBR, bundle:deploy-file, bundle:remote-clean) no longer use maven-compat's WagonManager, and no longer depend on the wagon-file and wagon-http providers Maven ships in lib/.

• RemoteFileManager looks the Wagon up by protocol in the plugin's container (the call WagonManager.getWagon made), takes credentials from the matching settings <server> through SettingsDecrypter, and keeps using the first active proxy (as before: no protocol match), whose password is now decrypted too. The server id is matched case-insensitively, as the maven-compat 3.8.1 the plugin builds against did. The Wagon is released after use.
• The plugin declares wagon-file and wagon-http 3.5.3; other protocols still come from build extensions.
• maven-compat stays for now: BundlePlugin, BundleAllPlugin and AbstractBaselinePlugin still use its ArtifactResolver, ArtifactCollector and MavenProjectBuilder (FELIX-6606).

Verified: install bundle:deploy -DremoteOBR against a file:// OBR and an HTTP OBR with and without Basic auth, run twice so repository.xml is created and then merged → passes on Maven 3.9.16 and 4.0.0-rc-7; on a 3.9.16 copy without lib/wagon-file* and lib/wagon-http*, master fails with Unsupported protocol: 'file' and this change passes. mvn verify in the module: 38 tests (9 new) and 14 ITs pass. Not run end to end: deploy-file, remote-clean, scp/sftp through an extension, a real proxy.

[paulrutter]

Thanks for this, the refactor itself looks good. I compared it with maven-compat 3.8.1, where getWagon(Repository) is just a lookup by protocol. Your replacement keeps the same behavior, including the case-insensitive server id match and decrypting the passwords. The tests are a nice addition too.

I have a couple of proposals and would like your feedback on them.

1. Bundling wagon-file and wagon-http.
   They are compile scope, so every user of the plugin, including those who only run bundle:bundle, resolves wagon-http and its transitive HTTP stack. That seems like a lot for goals I suspect few people use. What do you think about leaving the providers out? On a Maven without them, the existing “Unsupported protocol” error would apply. Users who need it could add the providers as a build extension, and we could say so in the goal documentation. If you see a reason to bundle them, for example Maven 4 without the providers, I’m open to it. In that case, could wagon-file alone be enough, or could we scope the providers more narrowly?

2. Lock handling.
   lockFile(...) runs before the try/finally in ObrDeploy, ObrDeployFile and ObrRemoteClean. If the remote repository is already locked, it throws before the finally. The Wagon is then never disconnected or released, and with this PR it also never goes back to the container. I’d suggest moving the call inside the try, or wrapping it so disconnect() always runs. This exposure predates the PR. Would you be willing to include it here, or would you rather I do it as a follow-up?

Two smaller points, optional:

In connect(), a RuntimeException from the decrypter or the wagon skips releaseWagon().
Decryption problems (SettingsDecryptionResult.getProblems()) are ignored, so a bad master password shows up as a plain “Authentication failed”. maven-compat behaved the same way.

Finally, a question: do you use the remote OBR goals yourself? The OBR code has seen no functional change since 2020, and I’m considering deprecating the goals. Knowing whether anyone relies on them, and whether you tested deploy-file and remote-clean, would help me decide.