How to avoid "The job exceeded the maximum time limit for jobs, and has been terminated." when accessing mvnsearch.org on Travis CI?

Question

Since approx. 72h I'm getting The job exceeded the maximum time limit for jobs, and has been terminated. on TravisCI which seems to be related requesting artifacts from mvnsearch.org, e.g. https://travis-ci.org/document-scanner/document-scanner-aggregator/builds/266942578. I assume it's a remote repository which I'm not using, but some of the project's dependencies are.

mavensearch.org seems to be unreachable or responding very slowly. I don't find any news on their operational status. It's odd that the issues isn't fixed within 72h, so I assume a long-time issue.

The only possible solution I could imagine would be to add the download and installation of a maven proxy to the Travis CI build script and proxy mavensearch.org in a Maven settings.xml file. Is there any way to avoid this?

It doesn't work to use the mirror element in ~/.m2/settings.xml because it references the repository id in referenced POMs which can be those of transitive dependencies and can change if snapshots are used and need to be checked and eventually adjusted after every version change.

Answer 1

A couple of actions may be done:

1. The Common Build Problems: My builds are timing out - Travis CI answer provides a couple of solutions. One of them is «to extend the wait time» for the Maven process.
2. Enable caching of the Maven dependencies: Caching Dependencies and Directories: Caching directories (Bundler, dependencies): Arbitrary directories - Travis CI.
3. Use a repository manager: «act as dedicated proxy server for public Maven repositories».
   Additional references:
   1. Nexus example:
      • Maven Repositories - Nexus Repository Manager 3 - Sonatype Help. See «Browsing and Searching Maven Repositories» (general information) and «Configuring Apache Maven» (settings.xml-related information) sections.
      • «User manual» for the use case: Using Nexus 3 as Your Repository – Part 1: Maven Artifacts | TheNEXUS.
   2. The general question: How does one mirror a maven repository?.

Answer 2

Enabling caching on Travis CI by adding

cache:
  directories:
  - $HOME/.m2

to .travis.yml turned out to be not the solution at all or only a temporary one (for approx. 40 builds over the last week; because mvnsearch.org became available again or for other reasons hard to figure out), I found the following more promising solution (which is way easier than setting up a Nexus repository manager instance which can be used as a mirror):

Add

- echo -e '<?xml version="1.0" encoding="UTF-8"?>\n<settings xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd" xmlns="http://maven.apache.org/SETTINGS/1.1.0"\n    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">\n  <mirrors>\n    <mirror>\n      <id>mvnsearch-unavailable</id>\n      <name>mvnsearch-unavailable</name>\n      <mirrorOf>mvnsearch</mirrorOf>\n      <url>http://repo1.maven.org/maven2</url>\n    </mirror>\n  </mirrors>\n  <profiles>\n    <profile>\n      <id>no-mvnsearch</id>\n      <repositories>\n        <repository>\n          <id>mvnsearch</id>\n          <url>http://www.mvnsearch.org/maven2</url>\n          <releases>\n            <enabled>true</enabled>\n          </releases>\n          <snapshots>\n            <enabled>true</enabled>\n          </snapshots>\n        </repository>\n      </repositories>\n    </profile>\n  </profiles>\n  <activeProfiles>\n    <activeProfile>no-mvnsearch</activeProfile>\n  </activeProfiles>\n</settings>' > $HOME/.m2/settings.xml
- cat $HOME/.m2/settings.xml

to .travis.yml which will override uses of http://www.mvnsearch.org/maven2 in any hard to control transitive dependency and use the Maven central repository http://repo1.maven.org/maven2 which covered all dependencies in my case (it might not in other cases).

Note that Murphy's Law applies as it does to anything: Maven 3.1.1 ignores this setting even though it claims to use the mirror in its debug output (ouch!).

The build is now 7 minutes faster than it was with the temporary working caching solution.