Error grabbing Grapes ... unresolved dependency ... not found

Question

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!!!!

Answer 1

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)