When a Maven build fails because an external dependency is unavailable, the fix depends on whether the repository is temporarily down, misconfigured, or the artifact has genuinely been removed or relocated. The general approach is to verify configuration first, then work around unavailability if needed.
Key Points: • Verify the repository URLs in pom.xml (or settings.xml mirrors) are correct, reachable, and not blocked by network/firewall rules. • Check whether the artifact was removed, renamed, or moved to a different repository (common with deprecated or relocated libraries). • Add an alternative repository that hosts the same artifact if the primary one is down or doesn't have it. • As a fallback, manually download the JAR and install it into the local repository with mvn install:install-file, specifying groupId, artifactId, version, and packaging. • For longer-term resilience, run a repository manager like Nexus or Artifactory that caches artifacts locally so a single upstream outage doesn't block every developer.
Example: When an internal library's snapshot version was purged from the artifact repository, the immediate fix was to obtain the JAR from a teammate and run mvn install:install-file to place it in the local repository, unblocking the build while the artifact was republished.
Code Example:
mvn install:install-file -Dfile=library-1.0.0.jar -DgroupId=com.example -DartifactId=library -Dversion=1.0.0 -Dpackaging=jarInterview Tip: A concise interview answer is:
"First I'd check that the repository URLs in pom.xml and settings.xml are correct and reachable, since misconfiguration is the most common cause. If the artifact is genuinely unavailable, I'd either add an alternate repository that hosts it or manually install it into the local repo with install:install-file to unblock the build immediately."