Error deploying artifact: Failed to transfer file:XXXXX Return co de is: 401

本文介绍如何使用Maven的deploy命令将构件部署到Nexus服务器,并解决部署过程中可能出现的HTTP状态码405、401、403、400等错误。通过配置settings.xml文件和使用正确的仓库类型,确保部署过程顺利。
原文出处: http://www.javatang.com/archives/2010/01/23/4518375.html
原文出处: http://cloudera.iteye.com/blog/781160

怎样使用deploy命令部署构件到nexus服务器上可以参考经典的《Maven Definitive Guide》(Maven操作指南),书中的16.7节里面讲解的非常详细。假设我们在项目pom.xml文件中对maven服务器的设置信息如下:

1.<distributionManagement>
2. <repository>
3. <id>nexus-releases</id>
4. <name>Local Nexus Repository</name>
5. <url>http://192.168.1.99:8081/content/repositories/releases</url>
6. </repository>
7. <snapshotRepository>
8. <id>nexus-snapshots</id>
9. <name>Local Nexus Repository</name>
10. <url>http://192.168.1.99:8081/content/repositories/snapshots</url>
11. </snapshotRepository>
12. </distributionManagement>
里我要说的是在使用的过程中遇到的几个都是“Failed to transfer file”错误,错误信息如下格式:

rror deploying artifact: Failed to transfer file:… Return code is:4xx

就是说前面错误的信息都是一样的,只是后面返回的HTTP状态数字不同。

. Return code is: 405
这个问题害我查了两个多小时才发现错误的根源,简单的错误就是在Maven执行到上传文件到服务器的时候出现一个HTTP 405错误。开始的时候总以为是Maven本身的问题,所以在这个上面浪费了不少时间。后来仔细查了405错误的含义是“用来访问本页面的 HTTP 方法不被允许”,最后终于发现是因为前面repository的地址写错了,或者是端口写错,或者是地址中的某个单词拼错了,反正原因就是repository的地址写错了。

. Return code is: 401或者Return code is: 403
其实403错误就是“禁止访问”的含义,所以问题的根源肯定在授权上面。Maven在默认情况下会使用deployment帐号(默认密码deploy)登录的系统,但是关键的Nexus中Releases仓库默认的Deployment Policy是“Disable Redeploy”,所以无法部署的问题在这个地方,方法是将其修改为“Allow Redeploy”就可以了。


这里还没有结束,因为如果直接按照上面的设置的话会有一个安全问题,那就是这样所有的开发人员都可以将构件部署到Nexus的releases仓库中了,时间长了会导致这个仓库中非常乱,这也应该是nexus为什么默认情况下将Release仓库的发布权限关闭的原因了。解决这个问题的整体思路就是在部署构件的时候需要使用用户名和密码登录,操作如下:
(1) 首先将Releases仓库默认的Deployment Policy修改为“Allow Redeploy”;
(2) 然后在右边的Security下面的Users中,修改deployment帐号的密码,方法是在帐号上右键,然后选择“Set Password”(PS:这个操作我找了好久,后来无意中右键才找到,呵呵~~);

(3) 这个时候如果直接执行 mvn deploy 命令的话就又会出现401错误,还有一步就是将密码设置到Maven settings.xml中。打开settings.xml文件(${user.home}/.m/settings.xml或%{m2_home}/conf/settings.xml),找到<servers>,然后修改信息如下:

1.<server>
2. <id>releases</id>
3. <username>deployment</username>
4. <password>deploydv89</password>
5. </server>
6.
7. <server>
8. <id>snapshots</id>
9. <username>deployment</username>
10. <password>deploydv89</password>
11. </server>
里需要特别说明一句的是里面的id必须和你在项目pom.xml文件中distributionManagement下面设置的仓库id一致!当然了,这个里面你也可以设置admin帐号,或者参照deployment的权限手动添加新的帐号等等都是可以的。

然,问题到这里已经得到了比较完美的解放,但是如果有人还要较真的话会想到帐号的密码直接放到配置文件里面不是很安全。其实只要这里不建议放admin帐号,而deployment是无法登录的。如果非要更安全一些的话,也可以使用Maven 2.1.0之后所提供的密码加密功能,操作的步骤如下:
(1) 使用“mvn –encrypt-master-password xxx”或“mvn –emp xxx”创建一个主密钥,后面的xxx就是你所要设置的密钥的内容,这个密钥主要用于后面加密密码来用的;命令执行之后会产生一个类似{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}形式的字符串。
(2) 在${user.home}/.m/目录下创建一个名为settings-security.xml文件,我们将刚刚产生的主密钥放到这个文件中,文件的内容如下:

1.<?xml version="1.0" encoding="UTF-8"?>
2.<settingsSecurity>
3. <master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master>
4.</settingsSecurity>
意,这个settings-security.xml文件一定要放在${user.home}/.m/目录下面,而不能放在${m2_home}/conf目录下!
(3) 使用“mvn –encrypt-password xxx”或“mvn –ep xxx”命令对帐号的密码进行加密,后面的xxx就是帐号的密码,加密之后依然会产生一个“{xxx}”形式的字符串,将这个字符串替换上面settings.xml文件中的server下面的password节点内容即可。
还有一种更安全的方式,就是将主密钥放到U盘里面,具体的操作可以看下面的参考资料。

. Return code is: 400
400错误的含义是“错误的请求”,在这里的原因是往往是没有部署到nexus的仓库中。nexus的repository分三种类型:Hosted、Proxy和Virtual,另外还有一个repository group(仓库组)用于对多个仓库进行组合。部署的时候只能部署到Hosted类型的仓库中,如果是其他类型就会出现这个400错误。

有一种情况也会出现400错误,就是默认情况下部署构件到Releases仓库中有时也会出现400错误,这个原因就像上面提到的那样,Nexus中Releases仓库默认的Deployment Policy是“Disable Redeploy”,所以无论你在settings.xml文件中将server的username设置为deployment还是使用admin都是无法部署的,就会出现这个400错误。这个问题也困扰了我好长时间,而且我还看到网上有人说admin没有部署构件的权限,这个是不对的。修改的方法可以参考上面第2条的做法。
在部署 Web 应用时,如果出现错误提示 `Artifact MyWeb:Web exploded: Error during artifact deployment`,通常意味着在 IntelliJ IDEA 中尝试将一个“Exploded”格式的 Web 应用部署到服务器(如 Tomcat)时发生了问题。该错误可能由多种原因引起,包括配置错误、路径问题、端口冲突、依赖缺失等。以下是一些常见的排查与解决方法。 ### 1. 检查 Tomcat 配置与部署方式 确保 Tomcat 服务器在 IntelliJ IDEA 中已正确配置,并且选择的部署方式为 `Web Application: Exploded`。Exploded 模式表示项目不会被打包为 WAR 文件,而是以文件夹形式部署,便于快速调试。如果配置缺失或错误,可能会导致部署失败[^2]。 - 打开 `Edit Configurations`,检查是否已添加 Tomcat Server。 - 确保在 `Deployment` 选项卡中添加了正确的 Artifact(如 `MyWeb:Web exploded`)。 - 验证部署路径是否正确,通常默认路径为 `webapps` 目录下的某个子目录。 ### 2. 检查服务器日志以定位错误 Tomcat 的日志文件通常位于 `logs` 目录下,其中 `catalina.out` 或 `localhost.log` 包含了部署过程中的详细错误信息。通过分析这些日志,可以快速定位问题根源。 - 查看日志中是否出现 `ClassNotFoundException` 或 `NoClassDefFoundError`,这可能意味着某些依赖库未被正确加载。 - 注意是否有 `Context` 初始化失败的提示,例如 `Failed to start component [StandardEngine...`。 - 如果日志提示端口冲突,检查 `server.xml` 文件中的端口设置并进行调整。 ### 3. 验证项目结构与 web.xml 配置 如果项目结构或 `web.xml` 配置有误,也可能导致部署失败。例如,Servlet 映射配置错误会导致服务器启动失败。 - 确保 `WEB-INF/web.xml` 中的 `<url-pattern>` 正确配置,例如应以 `/` 开头,如 `<url-pattern>/two</url-pattern>`[^4]。 - 检查 `WEB-INF/lib` 目录是否包含所有必要的 JAR 文件。 - 确保 `WEB-INF/classes` 中包含编译后的类文件,并且包结构正确。 ### 4. 清理缓存与重新部署 有时旧的部署残留可能导致冲突。尝试以下操作: - 删除 Tomcat 的 `work` 和 `temp` 目录下的内容。 - 删除 `webapps` 中旧的部署目录(如 `MyWeb`)。 - 在 IntelliJ IDEA 中执行 `Build > Rebuild Project` 并重新部署。 ### 5. 检查项目输出路径 确保 IntelliJ IDEA 正确生成了 Exploded 格式的部署目录。通常,该目录位于项目的 `out/artifacts/` 子目录下。如果该目录不存在或内容不完整,可能是构建过程中出现问题。 - 检查 `Build > Build Artifacts` 是否已执行成功。 - 确认 `WEB-INF` 目录下是否包含必要的配置文件和类文件。 ### 示例:检查日志并定位错误 ```bash # 查看 Tomcat 日志 tail -f /path/to/tomcat/logs/catalina.out ``` 在日志中查找类似以下的关键错误信息: ``` SEVERE: Error deploying web application directory [/path/to/tomcat/webapps/MyWeb] java.lang.IllegalStateException: ContainerBase.addChild: start: ... ``` 根据日志提示,进一步检查相关类或配置文件。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值