错误抓取Grapes ...无法解析的依赖关系...未找到 [英] Error grabbing Grapes ... unresolved dependency ... not found

问题描述

UPDATE 8/6：

更强大的日志记录显示，从高速缓存中删除旧jar时出现问题，导致致命的未找到错误。还有其他类似于此的线程，但只有当某人使用他们的IDE锁定文件时。我们正在从Jenkins运行一个简单的Groovy脚本，并且没有人登录到此框。

我们在失败后立即运行process explorer，并且没有锁。然后我用詹金斯用来运行脚本的用户登录，并且删除文件时没有错误。

另外，似乎IVY 2.1中有一个修复程序，当jar无法删除时不会失败，而且我在Ivy 2.2（Groovy 1.8.4）上。

 无法从缓存中删除过期的工件：C：\ Users \ myUser \.groovy \ grapes \ com.abc\xyz\jars\xyz-1.496.jar 
  

然后false（？）错误：

 抓取：java.lang.ExceptionInInitializerError 
 java.lang.ExceptionInInitializerError 
导致：java.lang.RuntimeException：错误抓取Grapes  -  [未解析的依赖项：com.abc＃xyz; 1. +：未找到] 
 at smokeTestSuccess。< clinit>（smokeTestSuccess.groovy）$ b $有趣的是，这种情况每天都会在第一次脚本在上午5点之后运行时发生。我猜想缓存在5am时会通过一些默认配置失效？这是一些线索吗？
 
 
 
 
 
 
 原文： 
 
 
 
我在运行多个不同的Groovy脚本时会间歇性地发生错误，这些脚本全部共享相同的@Grab声明。 （改变文件名以保护无辜者）。首先是完整的Grab声明：
 
 $ $ p $  @GrabResolver（name ='libs.release'，root ='http：// myserver： 8081 / artifactory / libs-release'，m2compatible ='true'）@Grapes（[
 @Grab（group ='com.abc，module ='xy-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）
  

然后错误：



 捕获：java.lang.ExceptionInInitializerError 
 java.lang .ExceptionInInitializerError 
导致：java.lang.RuntimeException：错误抓取Grapes  -  [unresolved dependency：com.abc＃xyz; 1. +：not found] 
  

在进行大量的网络搜索之后，原因似乎总是非常简单，无论是以下两个基本问题之一：
1. Repository unreachable
2. jar文件不存在

然而，在artifactory日志中，我已经证明文件实际上正在下载中：

* Artifactory确实接受了下载请求：
2014-07-17 07:58:19,938 [接受下载] libs-release-local：com / a / b / c / xyz /1.477/xyz-1.477.jar匿名/ 165.226.40.155。

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

如果脚本只是重新启动，所有脚本都可以在100％的时间内运行。这一切都让我相信这个问题就是抓斗超时。理论上第二次运行脚本时，文件在缓存中，事情发生得更快，因此它不会失败。

对于上面的真实请求，我可以看到约20秒的时间在http请求下载。

问题：

1. 我的理论看起来正确吗？
   

2. 有没有办法增加脚本等待@Grab的时间解决？




3. 在@Grab语句中放置try / catch块是否是一个好主意？或者只是隐藏了真正的问题？






提前致谢!!!!

$ b $我认为我终于想出了自己的问题的答案。




我相信有Groovy 1.8.4（或Ivy 2.2）中的某种错误，尤其是因为这种行为确实反映了一个古老的记录的常青藤错误与这个确切的错误消息方案和行为。





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





我也不知道为什么jar不能被删除，没有任何东西能够锁定它们。我尝试将葡萄缓存移到不太安全的文件夹以排除许可问题，但这并没有帮助：

  -Dgrape.root = D：\ Temp \grapeCache 
  





---



UPDATE 8/19：




一旦我们升级到Groovy 2.3.6，错误就消失了，但我后来发现当使用1. +解析器时，该jar不再被下载。 defaultgrapeConfig.xml中的某些内容导致了问题。一切都终于正常工作后（除了Groovy升级），我们用我们自己的剥离文件使用这个命令行JAVA_OPT覆盖defaultgrapeConfig.xml：



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

其中有这些内容：



 < ivysettings> 
< settings defaultResolver =downloadGrapes/> 
< resolvers> 
< chain name =downloadGrapes> 
< / chain> 
< /解析器> 
< / ivysettings> 
  

另外：

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






1. 在Jenkins GUI中，更新作业：

   
   
   

   a。更新每个脚本的下拉列表：执行Groovy脚本> Groovy版本> Groovy-2.3.6

   
   
   

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

   -Dgrape.config = D：\ Software \ SfGrapeConfig.xml
   
   

   可选日志切换：-Dgroovy.grape.report.downloads = true -Divy.message.logger.level = 4




2. 在实际的Groovy脚本本身中，删除@GrabResolver注释中的这个选项：，m2compatible ='true'




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

   无法找到客户端或服务器在[无论JAVE_HOME是什么]下的jvm，请检查它是否包含所需类型的jvm

   
   

   的有效jdk / jre删除常规.exe& groovyw.exe从D：\ Software \ Groovy-2.3.6 \ bin（如果exe文件不存在，Jenkins groovy插件将使用这些文件的bat文件版本，并且它们处理32位/位问题比exe的好）

   
   

   UPDATE 8/6:

   The beefed up logging has shown me that there is an issue deleting the old jar from the cache, which leads to the fatal "not found" error. There are other threads similar to this, but only when someone is locking the file with their IDE. We are running a single groovy script from Jenkins, and no one is logged into this box.

   We ran process explorer right after the failure and there were no locks. Then I login with the user that Jenkins is using to run the script, and I get no error deleting the files.

   Also it seems there was a fix in IVY 2.1 to not fail when the jar cannot be deleted, and I'm on Ivy 2.2 (Groovy 1.8.4). What gives?

   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
   

   then the false(?) error:

   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)
   

   Interestingly enough, this happens everyday the first time the script is run after 5am. I guess the cache gets invalidated through some default config at 5am? Is this some kind of clue??

   ---

   Original post:

   I am intermittently getting an error when running a number of different Groovy scripts which all share an identical @Grab declaration. (file names changed to protect the innocent). First the full Grab declaration:

   @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)
   

   Then the error:

   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]
   

   Upon doing numerous internet searches, the cause always seems to be very simple, either one of these two basic problems: 1. Repository unreachable 2. Jar file doesn’t exist

   However, in the artifactory logs, I've proven that the file is actually being downloaded:

   *Artifactory did accept the request for download: 2014-07-17 07:58:19,938 [ACCEPTED DOWNLOAD] 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 did deliver 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

   The scripts all work about 100% of the time if they are simply restarted. This all leads me to believe that the issue is the Grab timing out. Theoretically the second time I run the script, the file is in the cache, and things happen faster, thus it doesnt fail.

   For the above real request, I can see about 20 seconds of elapsed time in the http log from request to download.

   Questions:

   1. Does my theory seem correct?

   2. Is there a way to increase the amount of time that the script will wait for the @Grab to resolve?

   3. Does putting a try / catch block around the @Grab statements seem like a good idea? Or will that just hide the real problem?

   thanks in advance!!!!

   解决方案

   I think I finally figured out the answer to my own question.

   I believe there is some sort of bug within Groovy 1.8.4 (or Ivy 2.2), especially since this behavior does mirror an ancient documented Ivy bug with this exact error message scheme and behavior.

   Upgrading to Groovy 2.3.6 (which includes Ivy 2.3) appears to solve the issue.

   I also still have no idea why the jars cannot be deleted, nothing is locking them. I experimented with moving the grape cache to a less secure folder to rule out a permission issue, but this didn't help:

   -Dgrape.root=D:\Temp\grapeCache
   

   ---

   UPDATE 8/19:

   Once we upgraded to Groovy 2.3.6, the error went away, but I then figured out that the jar was no longer being downloaded at all, when using the "1.+" resolver. Something in the defaultgrapeConfig.xml was causing an issue. Everything is finally working properly after (in addition to the Groovy upgrade) we overrode defaultgrapeConfig.xml with our own stripped down file using this command line JAVA_OPT:

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

   which had these contents:

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

   ALSO:

   For completeness (further steps):

   1. In Jenkins GUI, update the job(s):

      a. Update the drop down for each script: Execute Groovy Script > Groovy Version > Groovy-2.3.6

      b. Update the JAVA_OPTS for each script (have to click the ‘advanced’ button under the script to see JAVA_OPTS):

      -Dgrape.config=D:\Software\SfGrapeConfig.xml

      Optional logging switches: -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4

   2. In the actual Groovy script itself, delete this option within the @GrabResolver annotation: , m2compatible = 'true'

   3. If you get this or a similar error:

   "could not find client or server jvm under [Whatever JAVE_HOME is], please check that it is a valid jdk / jre containing the desired type of jvm"

   Delete groovy.exe & groovyw.exe from D:\Software\Groovy-2.3.6\bin (if the exe’s do not exist, the Jenkins groovy plugin will use the bat file versions of these, and they handle the 32-bit / 64-bit problem better than the exe’s)

   这篇关于错误抓取Grapes ...无法解析的依赖关系...未找到的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！