Keywords: Maven | DependencyResolutionException | HTTP repository blocking
Abstract: This article delves into the DependencyResolutionException error in Maven builds, particularly caused by the default blocking of HTTP repositories since Maven 3.8.1. It first analyzes the core content of the error message, including how Maven's default HTTP blocking mechanism works and its security background. Then, it details three solutions: modifying the settings.xml file to add mirrors with the blocked property set to false for allowing specific HTTP repository access; directly commenting out the default HTTP blocking mirror in Maven configuration; and creating custom settings files in the project directory for team collaboration and CI/CD environments. Each method is accompanied by detailed code examples and configuration explanations, along with an analysis of applicable scenarios and potential risks. Finally, the article summarizes best practice recommendations, emphasizing the importance of balancing security and convenience, and provides further debugging and optimization suggestions.
Background and Error Analysis of Maven Dependency Resolution Exception
In Maven build processes, DependencyResolutionException is a common error often related to the download and resolution of dependencies. Based on the provided Q&A data, the user encountered this exception when running the mvn clean package command, with the error message clearly stating: Blocked mirror for repositories: [EBI (http://www.ebi.ac.uk/intact/maven/nexus/content/repositories/ebi-repo/, default, releases+snapshots), releases (http://gose.fiehnlab.ucdavis.edu:55000/content/groups/public, default, releases+snapshots)]. This indicates that Maven was blocked from downloading dependencies from HTTP repositories, leading to build failure.
The root cause of this issue lies in the security enhancements introduced in Maven version 3.8.1. Since this version, Maven has included a default HTTP blocking mirror in its configuration to prevent downloads from insecure HTTP repositories, reducing security risks such as man-in-the-middle attacks. The default mirror configuration is typically located in the ${MAVEN_HOME}/conf/settings.xml file, with its mirrorOf property set to external:http:*, meaning all requests to external HTTP repositories are redirected to an invalid URL (e.g., http://0.0.0.0/), thereby blocking access. The maven-default-http-blocker in the error message is the identifier for this default mirror.
Solution 1: Modifying settings.xml to Allow HTTP Repository Access
The best answer (Answer 1) provides a flexible and recommended solution by modifying the user-level ~/.m2/settings.xml file to add custom mirrors with the blocked property set to false, allowing access to specific HTTP repositories. This method does not affect the global Maven configuration and is suitable for personal development environments. Below is an example configuration for the EBI repository:
<mirror>
<id>insecure-repo</id>
<mirrorOf>external:http:*</mirrorOf>
<url>http://www.ebi.ac.uk/intact/maven/nexus/content/repositories/ebi-repo/</url>
<blocked>false</blocked>
</mirror>In this configuration, the mirrorOf property is set to external:http:*, indicating that this mirror will override all requests to external HTTP repositories, redirecting them to the specified URL. By setting blocked to false, Maven allows dependency downloads from this URL, resolving the build failure. Note that this method assumes the EBI repository mirrors all required HTTP repositories; if the project depends on multiple different HTTP repositories, more granular configuration may be needed, such as creating separate mirror entries for each repository.
Solution 2: Commenting Out the Maven Default HTTP Blocking Mirror
Answer 2 proposes a more direct approach by modifying the global Maven configuration file ${MAVEN_HOME}/conf/settings.xml to comment out the default HTTP blocking mirror. The specific operation is to locate the following configuration block and comment it out:
<!--
<mirror>
<id>maven-default-http-blocker</id>
<mirrorOf>external:http:*</mirrorOf>
<name>Pseudo repository to mirror external repositories initially using HTTP.</name>
<url>http://0.0.0.0/</url>
<blocked>false</blocked>
</mirror>
-->This method is simple and quick but has significant drawbacks. First, it affects all users and projects using this Maven installation, potentially reducing overall security. Second, if the Maven version is upgraded, the configuration file might be reset, causing the issue to recur. Therefore, this method is only recommended for temporary testing or when user-level settings are inaccessible, not for production environments or team collaboration scenarios.
Solution 3: Project-Level Custom Settings File
Answer 3 offers a project-level solution for team collaboration and CI/CD environments. By creating a .mvn folder in the project directory and placing a custom custom-settings.xml file inside, mirror configurations can be specified. For example, setting an unblocked mirror for the releases.java.net repository:
<settings xmlns="http://maven.apache.org/SETTINGS/1.2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.2.0 http://maven.apache.org/xsd/settings-1.2.0.xsd">
<mirrors>
<mirror>
<id>releases-java-net-http-unblocker</id>
<mirrorOf>releases.java.net</mirrorOf>
<name>releases.java.net</name>
<url>http://maven.java.net/content/repositories/releases/</url>
<blocked>false</blocked>
</mirror>
</mirrors>
</settings>Then, create a maven.config file in the .mvn folder with the content --settings ../.mvn/custom-settings.xml, so Maven automatically uses this settings file. Alternatively, specify it in the command line: mvn clean install --settings .mvn/custom-settings.xml. The advantage of this method is that the configuration is version-controlled with the project code, facilitating team sharing and CI/CD pipeline usage, but it requires ensuring all build environments can correctly read these files.
Best Practices and Security Considerations
When implementing the above solutions, security should be prioritized. The best practice is to upgrade repositories to HTTPS whenever possible, as HTTP connections are vulnerable to attacks, and Maven's default blocking mechanism is designed to mitigate such risks. If HTTP repositories must be used, it is recommended to adopt Answer 1's method, precisely controlling mirrors at the user level to avoid global modifications. Additionally, regularly review dependencies to remove unnecessary HTTP repository references.
For debugging, if the issue persists, run mvn clean package -X to enable debug logging for more detailed error information, helping identify other potential issues such as network connectivity or repository configuration errors. Also, check the repository definitions in pom.xml to ensure URLs are correct and no additional authentication is required.
In summary, Maven's dependency resolution exceptions often stem from changes in security policies. By properly configuring mirrors and the blocked property, build issues can be resolved without compromising security. In practical applications, choose the appropriate method based on environmental needs and maintain vigilance in dependency management.