CI systems such as Travis CI will kill builds if they don't produce any output for more than about ten minutes. For long-running repository-closing operations, sometimes brooklime won't say anything and the build will be killed as a result.

Have it speak every thirty seconds or so just to keep builds alive.

This has two parts: Walking a directory tree and producing a list of files to be uploaded, and the logic to perform the actual upload and aggressively retry in the case of failures.

The current logback.xml file included in the command-line frontend appears to be broken. It writes messages to stdout, and dumps configuration information on startup.

Allow for writing staging repository IDs to a file instead of stdout.

The Nexus server will occasionally return a better error message in an XML document. For example, if you try to upload a -SNAPSHOT version to a RELEASE repository, you'll get a precise error message telling you what you did wrong. Unfortunately, we're not parsing those, and will just log 400 BAD REQUEST. The full error is available if you turn on debug logging, but it would be better if you didn't have to.

This would be equivalent to the nexus-staging-plugin's rc-list-profiles command.

If an error occurs during the release phase (such as release rules failing in the remote repository), brooklime doesn't appear to notice. This is likely just a protocol error; we're not reacting to something that appears to be an error.

See: https://github.com/io7m/brooklime/actions/runs/288019827