A sample script ss.groovy:
#Grab(group='org.codehaus.groovy.modules.http-builder',
module='http-builder',
version='0.5.0')
import groovyx.net.http.HTTPBuilder
println('done')
for some reason takes ~25 seconds to load when run with
groovy ss.groovy
and ~5 seconds when run with
groovy -Dgroovy.grape.autoDownload=false ss.groovy
as per this StackOverflow explanation. I tried doing manual initialization with
Grape.enableAutoDownload = false
Grape.grab(group:'org.codehaus.groovy.modules.http-builder',
module:'http-builder',
version:'0.5.0')
import groovyx.net.http.HTTPBuilder
println('done')
but this fails on import with:
/tmp/ss.groovy: 3: unable to resolve class groovyx.net.http.HTTPBuilder
# line 3, column 1.
import groovyx.net.http.HTTPBuilder
^
Is there a contained way to either:
Make it not download the artifacts automatically (preferred, as it allows for solving other issues, e.g. external site down while an artifact already exists in the local cache)
Make it startup faster in any other way
By contained I mean that all additional instructions should be either within script or, if no such one exists, an acceptable default (e.g. don't check the cached artifacts for updates - I would still, however, like to have automatic downloads globally) to be put in some of groovy config files (e.g. ~/.groovy/grapeConfig.xml or similar).
Update: The issue has been fixed, #GrabConfig(autoDownload=false) will be available in Groovy 2.2
Why not install a repository manager locally?
http://nexus.sonatype.org/
I use Nexus to proxy and cache all my 3rd party repositories. Groovy is the configured to retrieve from either it's local cache or Nexus:
<ivysettings>
<settings defaultResolver="downloadGrapes"/>
<resolvers>
<chain name="downloadGrapes">
<filesystem name="cachedGrapes">
<ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/>
<artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
</filesystem>
<!-- Local Nexus Repository -->
<ibiblio name="nexus" root="http://localhost:8081/nexus/repositories/public" m2compatible="true"/>
</chain>
</resolvers>
</ivysettings>
This doesn't seem to be possible with the current (Groovy 1.8.1) implementation. I created an improvement ticket: http://jira.codehaus.org/browse/GROOVY-4943.
Related
I'm trying to write a Groovy script that depends on the HTTPBuilder library. I'm trying to add this as a dependency of my script via the #Grab annotation shown below
#Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.7.1')
import groovyx.net.http.HTTPBuilder
// rest of script omitted
But when I run this script I get the error:
java.lang.RuntimeException: Error grabbing Grapes -- [download failed: commons-lang#commons-lang;2.4!commons-lang.jar]
I've tested using #Grab to add other dependencies to my script, and the same problem does not occur, why can't I add HTTPBuilder?
Grape may be configured to only look in your local Maven repo for dependencies. To instruct it to also check online repositories, create a config. file ~/.groovy/grapeConfig.xml and add something like the following to it
<ivysettings>
<settings defaultResolver="downloadGrapes"/>
<resolvers>
<chain name="downloadGrapes">
<filesystem name="cachedGrapes">
<ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/>
<artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
</filesystem>
<!-- todo add 'endorsed groovy extensions' resolver here -->
<ibiblio name="codehaus" root="http://repository.codehaus.org/" m2compatible="true"/>
<ibiblio name="ibiblio" m2compatible="true"/>
<ibiblio name="java.net2" root="http://download.java.net/maven/2/" m2compatible="true"/>
</chain>
</resolvers>
</ivysettings>
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:
Does my theory seem correct?
Is there a way to increase the amount of time that the script will wait for the #Grab to resolve?
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):
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
In the actual Groovy script itself, delete this option within the #GrabResolver annotation: , m2compatible = 'true'
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)
In my cucumber -jvm, Maven, junit Setup I have my testRunner file as
package com.lebara.testrunner;
import cucumber.junit.Cucumber;
import org.junit.runner.RunWith;
#RunWith(Cucumber.class)
#Cucumber.Options(
glue = {"com.lebara.stepdefs","com.lebara.framework.main", "com.lebara.testrunner"},
features = "C:/Users/sarthak.dayanand/Documents/WebRefreshTest/CukeAutomation/LebaraWebAutomationTest1/src/main/resources",
format = {"pretty", "html:target/cucumber-html-report", "json-pretty:target/cucumber-report.json"},
tags = {"#UserJourney"}
)
public class RunCukesTest {
}
I have my feature file in the above mentioned directory.
If I run it, I get the following exception:
cucumber.runtime.CucumberException: No features found at [C:/Users/sarthak.dayanand/Documents/WebRefreshTest/CukeAutomation/LebaraWebAutomationTest1/src/main/resources/cucumber]...
If I remove the "features" option in the testrunner, it tries to look for feature files in the same directory as my testrunner.java
cucumber.runtime.CucumberException: No features found at [com/lebara/testrunner]
And if I put the feature files there, it works.
My question is why is my feature file not being picked up from my previous location, which I thought to be the default file structure for cucumber - maven setup.
How do I make it pick up from there? Help appreciated.
Where exactly are your test runner and feature files? I've got the following setup which works perfectly:
src/test/
java/
com/mypackage/
TestRunner.java
StepDefinition.java
resources
com/mypackage/
fancy.feature
The Maven/Cuke conventions will have the tests executed from the tests/java directory and the feature files found in the test/resources directory. My test runner is basically the same as yours but with less options:
import cucumber.api.junit.Cucumber;
import org.junit.runner.RunWith;
#RunWith(Cucumber.class)
#Cucumber.Options(format = {"pretty"})
public class TestRunner { }
Hope this helps if you hadn't already found an answer.
I have a setup similar to yours (not using the Maven/Cucumber conventions). In my options, I don't specify the path from root, but from the project's source folder where the features are held. It makes sense, since otherwise the tests would only be runnable from your machine.
In your case, I think it should be:
features = "src/main/resources"
Just add features = { "classpath:features/feature.feature"}, and the feature must under test/resources/features/feature.feature.
#CucumberOptions(
format = {"pretty", "html:target/html"},
features = {"classpath:features/feature.feature"},
snippets = SnippetType.CAMELCASE
Note classpath.
When you compile your code if you are using maven open up target/test-classes/features and you will see feature.feature
//Removing the space between "**classpath**" and "**:com/**" helped.
#RunWith(Cucumber.class)
#CucumberOptions(
features = {"classpath:com/tk/feature/"}, //NOTE: NO SPACE
glue = {"classpath: com.tk.cucumber"},
plugin = {
"pretty",
"html:build/reports/cucumber"
,"json:build/reports/cucumber-tests/test.json"}
)
public class RunAPITests {}
If you are providing the complete path of the feature file i.e.
"C:/Users/sarthak.dayanand/Documents/WebRefreshTest/CukeAutomation/LebaraWebAutomationTest1/src/main/resources" as in your query, try again by replacing the '/' character with '\\'(double back slash) as below.
"C:\\Users\\sarthak.dayanand\\Documents\\WebRefreshTest\\CukeAutomation\\LebaraWebAutomationTest1\\src\main\\resources\\abc.feature"
This is a git repo which uses the latest cucumber version : Cucumber- Example
Clone this repo and run it in your local machine. The #Given is defined and it should pass. The #Then and #When should be shown as undefined.
This is how the output for it should look :
Output for the Belly feature
Use the structure mentioned :
src / test / java/ io /cucumber / {Step definitions java and run cucumber test files here}
src /test / resources/ io/ cucumber / {feature files here}
You can run the gradle build using ./gradlew clean build
and the cucumber test using ./gradlew clean test --info
If this works, then use the same format in your project.
Just changing .Feature to .feature the problem got resolved for me.
Also make sure the path for feature is righly mention in CucumberOptions as per your feature folder
Some of the online tutorial have mentioned .Feature which brings this problem
so changing the case will solve this problem
There is another instance in which 'Feature Not Found' error occurs. I am posting the solution under this answer as there is no similar question.
I got this error when trying to run the Runner file first time after setting up Cucumber project in Maven. The solution i found was as follows: Go to the folder in which the 'feature' file is present in Windows Explorer. Check the size of the feature file you are trying to run. If the size is '0' KB, it will show the 'Feature Not Found' error. Make some changes to file until a value greater than zero is displayed. Run again after making changes.
#RunWith(Cucumber.class)
#CucumberOptions(
features = {"src/main/resources/cucumber/features"},//your feature path
tags = "not #Wip",
glue = {"classpath:steps"},
plugin = {"pretty", "html:target/cucumber/html"})
You must set the feature directory correctly
By putting the feature file under src/test/java where the runner and steps file or
by putting it under src/main/java the problem will get resolved.
I am trying to configure Cruisecontrol.net for UCM Clearcase for the first time. Following is the sourceControl tag in the ccnet.config file:
<sourcecontrol type="clearCase">
<branch>123_India_Release</branch>
<autoGetSource>true</autoGetSource>
<viewName>admin_123_CRUISE</viewName>
<viewPath>$(ViewDirectory)</viewPath>
<useLabel>false</useLabel>
<useBaseline>false</useBaseline>
<executable>cleartool.exe</executable>
</sourcecontrol>
I constantly receive the following error:
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control
operation failed: cleartool: Error: Not an object in a vob: "PATH TO
THE VIEW"
When I run cleartool from an arbitrary directory with the following parameters:
cleartool.exe lshist -r -nco -branch "123_India_Release" -since
05-Dec-2012.14:38:18 -fmt
I get the same error. But if I change the working directory to $(ViewDirectory) before running cleartool, it runs fine.
How should I make Cruisecontrol.net run cleartool.exe from the $(ViewDirectory)?
I have already tried adding <workingDirectory>$(ViewDirectory)</workingDirectory> tag before <executable>cleartool.exe</executable> but it did not work.
Any help would be appreciated.
EDIT 1:
As a workaround I have done the following:
<exec>
<executable>cleartool.exe</executable>
<baseDirectory>d:\Workspace\123_India_Release\VOB</baseDirectory>
<buildArgs>update -force</buildArgs>
<buildTimeoutSeconds>6000</buildTimeoutSeconds>
</exec>
I have added this to the tasks tag. I have configured an hourly trigger which does the following:
1) Update snapshot view
2) Build the VS 2010 solutions mentioned in the tasks tag.
The limitations are:
1) The trigger is hourly. I want it to be a commit based trigger.
2) This is a workaround
EDIT 2:
Further experimentation revealed that the ccnet.exe works fine. It does all that is needed. The issue is caused by the service ccservice.
I have stopped ccservice for now and started ccnet.exe. I plan to leave it running.
The View directory isn't enough: you must specify a vob.
See for instance:
"clearfsimport: Error: Not an object in a vob: "\"." (as an illustratio of that error message)
this thread (or this one): "You have to specify explicitly the VOB(s) to check for modification set"
The path should looks like:
<viewPath>Drive:\path\to\view\vobname</viewPath>
If your $(ViewDirectory) already references Drive:\path\to\view, then you could use:
<viewPath>$(ViewDirectory)\vobname</viewPath>
I'm working with the latest CruiseControl.Net 1.5.7256.1.
I'm trying to use one of the system parameters, CCNetWorkingDirectory under sourcecontrol block and the project failed to recognize this parameter.
<sourcecontrol type="svn">
<trunkUrl>https://padev/svn/physical/Source</trunkUrl>
<workingDirectory>$[CCNetWorkingDirectory]\SVN\Source</workingDirectory>
<username>ccnet</username>
<password>hidden</password>
</sourcecontrol>
I also tried it as $CCNetWorkingDirectory, $(CCNetWorkingDirectory), Non of these option worked.
Thank you
You got trapped. I think almost anybody who starts with CCNET tries to access CCNetWorkingDirectory inside CCNET configuration. This is not possible. Find my answer on a similar question here.
I don't know in which version things changed but as of version 1.8 you can use what they call: System Paremeters as documented here:
http://confluence.public.thoughtworks.org/display/CCNET/Dynamic+Parameters
and it works for me as in this sample configuration:
<project name="ProjectName" queue="myqueue" queuePriority="1">
<workingDirectory>path</workingDirectory>
...
<sourcecontrol type="svn">
<workingDirectory>$[$CCNetWorkingDirectory]</workingDirectory>
...
</sourcecontrol>