"Unrecognized option: --format=COBERTURAXML" in trying to convert JSCover report to cobertura xml - cobertura

I'm trying to convert JSCover to cobertura xml.
Based on what i've read the command is as follows:
java -cp JSCover-all.jar jscover.report.Main --format=COBERTURAXML REPORT-DIR SRC-DIRECTORY
But I get an error
"Error: Could not find or load main class jscover.report.Main"
Even if I set the fully qualified path of there the JSCover-all.jar is located.
So I tried including the JSCover-al.jar into the classpath and run the following command instead:
java -cp jscover.report.Main --format=COBERTURAXML target/local-storage-proxy target/local-storage-proxy/original-src
I no longer get the first error but i'm now getting the following error:
Unrecognized option: --format=COBERTURAXML
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I hope someone could help me with it. Many thanks!

The first attempt is the correct approach. The error means that JSCover-all.jar is not in the same directory that you are executing the command from. An absolute path to is not needed - a relative one will do.
In the second approach, you have passed 'jscover.report.Main' as the class-path to the JVM and '--format=COBERTURAXML' as parameter to the 'java' command.

Related

SoapUI specify alternate logdir as a property defined on the command line

I'm upgrading from SoapUI 5.4.0 to 5.7.0 and trying to put the log files in a specific directory. Note: The alternate error logs directory was working prior to the upgrade.
I have both the following specified in my JAVA_OPTS for SoapUITestCaseRunner
-Dsoapui.logroot="%SOAPUI_LOGSDIR%"
-Dsoapui.log4j.config="%SOAPUI_HOME%/soapui-log4j.xml"
In my soapui-log4j.xml I specify the error file as:
<RollingFile name="ERRORFILE"
fileName="${soapui.logroot}/soapui-errors.log"
filePattern="${soapui.logroot}/soapui-errors.log.%i"
append="true">
The error file then gets created without resolving ${soapui.logroot} e.g.
$ find . -name "*errors*"
./${soapui.logroot}/soapui-errors.log
I also tried it as lookup but ended up with this:
ERROR Unable to create file ${sys:soapui.logroot}/soapui-errors.log java.io.IOException: The filename, directory name, or volume label syntax is incorrect
Am I missing anything? Any ideas for next steps?
I tried replacing
fileName="${soapui.logroot}/soapui-errors.log"
with
fileName="${sys:soapui.logroot}/soapui-errors.log"
and it worked for me.
I no longer see unresolved '${soapui.logroot}' directory created.
A

SOOT - CompilationDeathException (and a phantom army)

here is the command I use on WIndows 10 command shell :
java
-cp .\soot-2.5.0.jar soot.Main
-cp ".;R:\...\OCLRuler\lib;C:\...\jdk1.8.0_144\bin"
-pp -process-dir R:\...\OCLRuler\src\
-src-prec java
-d R:\...\test\soot
-allow-phantom-refs
-main-class OCLRuler
When I execute it, I get the following output:
Soot started on Tue Sep 26 13:28:32 EDT 2017
Warning: java.dyn.InvokeDynamic is a phantom class!
Warning: Main is a phantom class!
Warning: MainMulti is a phantom class!
Warning: oclruler.a_test.MainRawTesting is a phantom class!
... all of them (100+ lines)...
Warning: oclruler.utils.ToolBox is a phantom class!
OCLRuler.java: Class "oclruler.genetics.EvaluatorOCL" not found.
OCLRuler.java: Class "oclruler.genetics.EvaluatorOCL" not found.
Exception in thread "main" soot.CompilationDeathException: Could not compile
at soot.javaToJimple.JavaToJimple.compile(JavaToJimple.java:104)
at soot.javaToJimple.InitialResolver.formAst(InitialResolver.java:117)
at soot.JavaClassSource.resolve(JavaClassSource.java:54)
at soot.SootResolver.bringToHierarchy(SootResolver.java:215)
at soot.SootResolver.bringToSignatures(SootResolver.java:239)
at soot.SootResolver.processResolveWorklist(SootResolver.java:154)
at soot.SootResolver.resolveClass(SootResolver.java:124)
at soot.Scene.loadClass(Scene.java:448)
at soot.Scene.loadClassAndSupport(Scene.java:433)
at soot.Scene.loadNecessaryClasses(Scene.java:1076)
at soot.Main.run(Main.java:167)
at soot.Main.main(Main.java:141)
All libs used in the OCLRUler project are included in OCLRUler/lib and all sources in OCLRuler/src. The output directory is not included in the soot directory. Also, the project does compile (I'm working on and with it). The . directory contains all soot/jasmin/heros jars.
Still, all classes are considered phantoms, and Soot compilation abords because (I guess) it lacks bodies from these classes. I mean that "EvaluatorOCL" (i.e., still guessing, the source of the CompilationDeathException) is a "Phantom class".
What's wrong ?
SHould I add all and every packages in Soot's classpath ?
I've tried all sorts of command line expressions - until I got profundly lost. Anybody has a clue on the matter ?
Thanks a lot.
Edouard
Changed the -pp -process-dir R:\...\OCLRuler\src\ argument for -pp -process-dir R:\...\OCLRuler\
and it seems to work fine... The phantoms are still strolling around, but there are result files in the output folder!
[edit:]
Oups, this is gona become a new question... The ouput files are... EMPTY !!!
As I said, there are still warnings about phantoms and outputs are generated for all files (java and class alike)
Why are they empty ??
[/edit]
This might well be a problem with Soot's source-code frontend, which is heavily outdated by now. I would recommend compiling the .java files to .class and then giving those to Soot.

How to run spock test from command line?

I have checked this link:
https://gist.github.com/ysb33r/5825457
It seems like that it can be run like this:
groovyc *.groovy
java -cp ~/.grapes/org.spockframework/spock-core/jars/spock-core-0.7-groovy-2.0.jar:$GROOVY_HOME/embeddable/groovy-all-2.1.4.jar:$GROOVY_HOME/lib/junit-4.11.jar:$GROOVY_HOME/lib/hamcrest-core-1.3.jar:.org.junit.runner.JUnitCore ExampleSpec
And I have added all third part jars to CLASSPATH,so all imports from these libs found.But all my own classes can't be found,and error message like this:
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
LoginTest.groovy: 11: unable to resolve class com.vsi.icareos.client.home.HomePage
# line 11, column 1.
import com.vsi.icareos.client.home.HomePage
^
LoginTest.groovy: 22: unable to resolve class LoginByPwdPage
# line 22, column 2.
LoginByPwdPage loginPage
^
LoginTest.groovy: 35: unable to resolve class LoginByPwdPage
# line 35, column 13.
loginPage=new LoginByPwdPage(browser,Consts.PAGE_ID)
^
3 errors
I guess that the option like:--sourcepath is needed,but I found this command option deprecated,so How to slove this problem?
I was able to run the tests described in the gist, but with modification of the groovyc to add the -cp flag with spock jar to it, also if you have the sources in sub-directories you should use **/*.groovy instead of *.groovy
Looking at the way you run the java command, it seams to be missing a space between . and org.junit.runner.JUnitCore
So instead of
java -cp ~/.grapes/org.spockframework/spock-core/jars/spock-core-0.7-groovy-2.0.jar:$GROOVY_HOME/embeddable/groovy-all-2.1.4.jar:$GROOVY_HOME/lib/junit-4.11.jar:$GROOVY_HOME/lib/hamcrest-core-1.3.jar:.org.junit.runner.JUnitCore ExampleSpec
I should be
java -cp ~/.grapes/org.spockframework/spock-core/jars/spock-core-0.7-groovy-2.0.jar:$GROOVY_HOME/embeddable/groovy-all-2.1.4.jar:$GROOVY_HOME/lib/junit-4.11.jar:$GROOVY_HOME/lib/hamcrest-core-1.3.jar:. org.junit.runner.JUnitCore ExampleSpec
Please note the space in the second.
The . is the current directory added to the classpath
hope this helps

Unable to run cucumber feature feature

I am unable to run the feature file. whenever i tried to run the file
i am getting the below stack trace
Exception in thread "main" Usage: java cucumber.api.cli.Main [options] [
[FILE|DIR][:LINE[:LINE]*] ]+
Options:
-g, --glue PATH Where glue code (step definitions and hooks) is loaded from.
-f, --format FORMAT[:PATH_OR_URL] How to format results. Goes to STDOUT unless PATH_OR_URL is specified.
Built-in FORMAT types: junit, html, pretty, progress, json.
FORMAT can also be a fully qualified class name.
-t, --tags TAG_EXPRESSION Only run scenarios tagged with tags matching TAG_EXPRESSION.
-n, --name REGEXP Only run scenarios whose names match REGEXP.
-d, --[no-]-dry-run Skip execution of glue code.
-m, --[no-]-monochrome Don't colour terminal output.
-s, --[no-]-strict Treat undefined and pending steps as errors.
--snippets Snippet name: underscore, camelcase
--dotcucumber PATH_OR_URL Where to write out runtime information. PATH_OR_URL can be a file system
path or a URL.
-v, --version Print version.
-h, --help You're looking at it.
cucumber.runtime.CucumberException: Unknown option: --plugin
at cucumber.runtime.RuntimeOptions.parse(RuntimeOptions.java:119)
at cucumber.runtime.RuntimeOptions.<init>(RuntimeOptions.java:50)
at cucumber.runtime.RuntimeOptions.<init>(RuntimeOptions.java:44)
at cucumber.api.cli.Main.run(Main.java:20)
at cucumber.api.cli.Main.main(Main.java:16)
Please help me to resolve the problem
You normally get this issue if you did not set cucumberOptions correctly on your cukes files.
For example:
#RunWith(Cucumber.class)
#CucumberOptions( dryRun = false, strict = true, features = "src/test/features/com/sample", glue = "com.sample",
tags = { "~#wip", "#executeThis" }, monochrome = true,
format = { "pretty", "html:target/cucumber", "json:target_json/cucumber.json", "junit:taget_junit/cucumber.xml" } )
public class RunCukeTest {
}
Hi I also had this issue as well, and I did the following to resolve it, thanks to the comments of Anusha from video https://youtu.be/pD4B839qfos
-the main trick is to firstly change the jar files you have as follows
cucumber-core-1.2.5.jar
cucumber-java-1.2.5.jar
cucumber-junit-1.2.5.jar
or any of the above, from 1.2.4 upwards
- also update the following selenium-server-standalone-2.42.0.jar and upwards
- also change the format keyword to plugin
Once you make the above changes, this should resolve your problem.

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

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)

Resources