fix(setup): read a file:/// repository from the local file system

[marevol]

Summary

On a server with no route to the Internet, plugins and themes can be installed by copying the Maven repository onto the server and pointing --repository at the copy. fess-setup install plugin ... --repository file:///path/to/repository/org/codelibs/fess/ instead fails with a stack trace (IllegalArgumentException: invalid URI scheme file) and exit code 1. Other failures print one error: ... line.

Cause

Every read in fess-setup goes through Downloader, and Downloader always uses java.net.http.HttpClient. That client only accepts http and https and throws an unchecked IllegalArgumentException for any other scheme. FessSetup.run catches only SetupException and IOException, so the exception reaches the user as a stack trace. A --repository with no scheme at all, such as a plain path, fails the same way.

Fix

Downloader reads a file: URI from the local file system and treats it like HTTP:

• A missing file counts as a 404. The optional .sha1 lookup (readStringIfPresent) and the "try the next source" logic (downloadIfPresent) therefore behave as they do over HTTP.
• A directory is read as the index a web server would list for it, so list plugins --repository file:///... works too.
• The artifact is copied through the same code as an HTTP download, including the .part file and the existing-size check. The HTTP body-writing code was moved into a shared helper for this.

maven-metadata.xml, the snapshot build metadata, the plugin jar, the theme archive and its theme-index.txt, and the published SHA-1 are all read through Downloader. Version resolution, installation and checksum verification therefore work against a file: repository without other changes. --repository already disables the GitHub download source, so nothing else goes to the network.

Downloader now refuses any scheme other than http, https and file, and any --repository with no scheme, with a SetupException. The user gets the usual single error: ... line instead of a stack trace. A file: URI that does not name an absolute local path is reported the same way.

The install plugin help mentions that a file:/// URL can name a local copy of the repository.

Tests

• DownloaderTest: reading a file: URL; a missing file fails readString/download and returns null from readStringIfPresent/downloadIfPresent; a directory is listed as an index; copying reports progress and leaves no .part file; an unsupported scheme and a URI with no scheme are refused with SetupException.
• FileRepositoryTest (new) builds a repository layout in a temporary directory (org/codelibs/fess/<artifact>/maven-metadata.xml, <version>/<artifact>-<version>.jar and .jar.sha1) and runs fess-setup against it:
  • install plugin fess-ds-git:15.9.0 --repository file:///... installs the jar and verifies its checksum without a warning.
  • A wrong .sha1 fails the install with error: Checksum mismatch ... and leaves no jar.
  • A version that is not in the repository fails with one error: line.
  • --repository ftp://... fails with one error: line.
  • Version resolution reads maven-metadata.xml from the file: repository.
  • list plugins lists the plugins in the repository directory and leaves out non-plugin artifacts.
• Without the Downloader change, 14 of these tests fail.
• mvn test -Dtest='org.codelibs.fess.setup.*Test': 226 tests, all pass.