MAVEN3.9.x中301问题及解决方法

本文主要是介绍MAVEN3.9.x中301问题及解决方法，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

《MAVEN3.9.x中301问题及解决方法》本文主要介绍了使用MAVEN3.9.x中301问题及解决方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面...

01、背景

为了提升maven客户端的构建速度，经过调研，了解到mvnd存在以下技术特性：

GraalVM的使用，mvnd使用GraalVM替代了传统的JVM，使得启动速度更快，占用的内存更少。GraalVM是一个高性能的运行时，它能够快速启动，并且具有较低的内存占用。这意味着mvnd在启动和运行时的性能都优于使用传统JVM的mvn。
缓存机制，mvnd对于Maven插件的缓存机制也有所改进。在jsmvn构建过程中，每次构建都需要重新加载和编译所有的Maven插件。而在mvnd中，这些插件被缓存在多个构建中，只有当插件的版本发生变化时，才会重新加载和编译。

基于以上优点，为支持mvnd功能，实现加速构建能力，用户需要将maven版本从3.6.x版本升级到3.9.x版本，用户升级之后在提交构建二进制制品过程当中发现maven 3.9.x版本的兼容性问题。后续就兼容性问题进行识别改造，完成需求交付。

02、现象

MAVEN3.9.x中301问题及解决方法

基于maven3.6.x版本执行deploy动作，所构建制品可以正常发布到nexus仓库。

MAVEN3.9.x中301问题及解决方法

基于maven3.9.x版本提交所构建制品失败，收到nexus服务“301”返回码。

03、分析原因

MAVEN3.9.x中301问题及解决方法

Figure 1 DEPLOY请求示意

用户在本地执行“mvn deploy” 命令之后，本地开始编译构建制品，构建完成之后开始交付所构建制品部署到nexus服务，在部署到nexus之前经由nginx进行代理，之后上传到nexus仓库。

MAVEN3.9.x中301问题及解决方法

Nginx.conf 配置片段

MAVEN3.9.x中301问题及解决方法

用户本地pom.XML配置片段

早期版本根据护网安全需求，需要把应用的原始请求资源路径屏蔽掉，在nginx.conf层面进行转发配置，针对用户在pomxml当中配置的屏蔽原始路径之后的仓库地址进行重定向。

针对maven3.6.x版本的交互过程进行分析

MAVEN3.9.x中301问题及解决方法

在javascriptmaven3.6.x版本的场景下，执行DEPLOY，观察到第一次请求打到nginx之后，nginx响应301永久重定向，并且在响应头location字段返回新的URL地址；
Maven3.6.x 拿到301重定向，根据location的地址，重新发起请求新的URL；
后续交互过程以相同方式完成交互，直至deploy完成。

针对maven3.9.x版本的交互编程过程进行分析

MAVEN3.9.x中301问题及解决方法

在maven3.9.x场景下，执android行deploy命令，请求到达nginx之后，给出相同的301响应，并且在响应头的location当中指定重定向之后的URL；
Maven在拿到重定向响应之后，忽略301，直接开启下一个步骤的请求；
在下一个步骤的交互里面，nginx涛声依旧……，然后就是我们在cmd上面看到的最终的失败的执行结果。

04、解决方案及验证

根据上面现象分析，经过验证发现是maven 3.9版本不处理301重定向，根据这个特性，针对nginx进行改造：

upstream nexus_server {
        server xxx.xxx.xxx.xxx:xxx max_fails=3 fail_timeout=900s weight=10;
    }
server {
        listen       80;
        server_name  test.repo.htsc;
        Access_log  /var/log/nginx/access.log  ;
        error_log  /var/log/nginx/access.log  ;
    location /
    {
          # 摘除/nexus或/nexus/content 
       rewrite ^/nexus/content/(.*)$ /$1 last; 
       rewrite ^/nexus/(.*)$ /$1 last; 
       # 将repositories替换为repository 
       rewrite ^/(.*)repositories(.*)$ /$1repository$2 last;     
……
        expires -1;
    }
}

针对nginx.conf进行改造，将rewrite 中permannet 永久重定向调整为last，在重写URI之后再次进入locate过滤，直至proxy_pass，将原来依赖客户端处理android301的逻辑调整为nginx自身完成URI转换和请求处理，改造之后既减少网络IO，每个请求省了一次交互，又提升了用户的使用体验，提升了deploy的效率。