Question

更新8/6：

增强的日志记录向我展示了从缓存中删除旧jar的问题，这导致了致命的“未找到”错误。还有其他与此类似的线程，但仅当有人使用IDE锁定文件时。我们正在运行Jenkins的一个groovy脚本，没有人登录到这个框。

我们在失败后立即运行了进程资源管理器，并且没有锁定。然后我使用Jenkins用来运行脚本的用户登录，删除文件时没有错误。

此外，似乎IVY 2.1中的修复程序在jar无法删除时没有失败，而且我正在使用Ivy 2.2（Groovy 1.8.4）。是什么给了什么？

Couldn't delete outdated artifact from cache: C:\Users\myUser\.groovy\grapes\com.a.b.c\x-y-z\jars\x-y-z-1.496.jar

然后是错误的（？）错误：

Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
at smokeTestSuccess.<clinit>(smokeTestSuccess.groovy)

有趣的是，每天早上5点之后运行脚本时都会发生这种情况。我想缓存在早上5点通过一些默认配置失效了？这是某种线索吗？

原帖：

我在运行许多不同的Groovy脚本时间歇地出错，这些脚本都共享一个相同的@Grab声明。（更改文件名以保护无辜者）。首先是完整的Grab声明：

@GrabResolver(name = 'libs.release', root = 'http://myserver:8081/artifactory/libs-release', m2compatible = 'true') @Grapes([
@Grab(group = 'com.a.b.c, module = 'x-y-z', version = '1.+', changing = true),
@Grab('commons-lang:commons-lang:2.3'),
@Grab('log4j:log4j:1.2.16'),
@Grab('gpars:gpars:0.12'),
@Grab('jsr166y:jsr166y:1.7.0'),
@Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.6'),
@Grab('org.apache.commons:commons-collections:3.2.1'),
@Grab('org.apache.httpcomponents:httpclient:4.2.2'),
@Grab('org.apache.httpcomponents:httpcore:4.2.3'),
@Grab('org.cyberneko.html:nekohtml:1.9.17'),
@Grab('xerces:xercesImpl:2.11.0'),
]) @GrabConfig(systemClassLoader = true)

然后是错误：

Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]

在进行多次互联网搜索后，原因似乎总是很简单，这两个基本问题都是： 1.存储库无法访问 2. Jar文件不存在

但是，在神器日志中，我已经证明该文件实际上已被下载：

* Artifactory确实接受了下载请求： 2014-07-17 07：58：19,938 [接受下载] libs-release-local：com / a / b / c / x-y-z / 1.477 / x-y-z-1.477.jar for anonymous / 165.226.40.155。

* Artifactory确实提供了jar： 20140717075820 | 156 | REQUEST | 165.226.40.155 | non_authenticated_user | GET | /libs-release/com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar | HTTP / 1.1 | 200 | 1276695

如果简单地重新启动脚本，那么这些脚本大约100％的时间都可以工作。这一切都让我相信问题是Grab超时。从理论上讲，第二次运行脚本时，文件位于缓存中，事情发生得更快，因此它不会失败。

对于上述实际请求，我可以看到http日志中从请求下载大约20秒的经过时间。

问题：

我的理论是否正确？
有没有办法增加脚本等待@Grab解析的时间？
在@Grab语句周围放一个try / catch块似乎是个好主意吗？或者这只会隐藏真正的问题？

提前致谢!!!!

Answer 1

我想我终于找到了自己问题的答案。

我相信Groovy 1.8.4（或Ivy 2.2）中存在某种错误，特别是因为这种行为确实反映了一个古老的文档常春藤错误，并带有这种确切的错误消息方案和行为。

升级到Groovy 2.3.6（包括Ivy 2.3）似乎可以解决这个问题。

我还不知道为什么不能删除罐子，没有什么东西可以锁定它们。我尝试将葡萄缓存移动到不太安全的文件夹以排除权限问题，但这没有帮助：

-Dgrape.root=D:\Temp\grapeCache

更新8/19：

一旦我们升级到Groovy 2.3.6，错误就消失了，但是当我使用“1. +”解析器时，我发现罐子根本不再被下载了。 defaultgrapeConfig.xml中的某些内容导致了问题。除了Groovy升级之外，我们使用此命令行JAVA_OPT覆盖了defaultgrapeConfig.xml和我们自己的精简文件，所有内容终于正常工作了：

-Dgrape.config=D:\Temp\myGrapeConfig.xml

有这些内容：

<ivysettings>
  <settings defaultResolver="downloadGrapes"/>
    <resolvers>
    <chain name="downloadGrapes">
    </chain>
    </resolvers>
</ivysettings>

同时

为了完整性（进一步的步骤）：

在Jenkins GUI中，更新作业：

一个。更新每个脚本的下拉列表：执行Groovy脚本＆gt; Groovy版本＆gt; Groovy的2.3.6

湾更新每个脚本的JAVA_OPTS（必须单击脚本下的“高级”按钮才能看到JAVA_OPTS）：

-Dgrape.config = d：\ SOFTWARE \ SfGrapeConfig.xml

可选的日志记录开关：-Dgroovy.grape.report.downloads = true -Divy.message.logger.level = 4

在实际的Groovy脚本中，在@GrabResolver注释中删除此选项：，m2compatible ='true'

如果您收到此错误或类似错误：

“在[无论JAVE_HOME是什么]下找不到客户端或服务器jvm，请检查它是否是包含所需类型jvm的有效jdk / jre”

删除groovy.exe＆amp;来自D：\ Software \ Groovy-2.3.6 \ bin的groovyw.exe（如果exe不存在，Jenkins groovy插件将使用这些的bat文件版本，并且它们更好地处理32位/ 64位问题比exe的）

抓住Grapes的错误......未解决的依赖...未找到

1 个答案: