I have a script that I quickly put up using a #Grab annotation to import a package - namely HttpBuilder. Now I would like to actually install HttpBuilder and get rid of the annotation before putting the script in production - I do not want to grab the dependency dynamically on the prod server.
How do I actually tell Grape to install the dependency once and for all? Is there even a way to do this? If not, how should I install this package before deploying?
EDIT Following the advice from tim_yates, I donwloaded all teh JARs from HttpBuilder website, and added them to the classpath. But, when I run groovy -cp dependencies/* myApp.groovy what I get is a bunch of errors like
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/path/to/dependencies/httpclient-4.0.3.jar: 1: unexpected char: 0x3 # line 1, column 3.
PK
^
What does this mean?
If you go to the Downloads page for HttpBuilder, you can follow the links in the first paragraph and download the http-builder-xxx-all.zip for the release you want...
Expand this, and it contains the jar, and the dependency jars in the dependencies folder
Then, just add them to the classpath in the usual way and get rid of the #Grab line
Related
We have multiple testing repos, and some of the scenarios depend on the steps already created in a separate repo, so I'm trying to build the JAR file and include it in the external libraries of the other repo. Then I define my gluecode in the IntelliJ runner with two separate lines:
com.edge.automation
C:\Users\MY_NAME\.m2\repository\com\reissue-automation\2.0.3-SNAPSHOT\reissue-automation-2.0.3-SNAPSHOT-tests.jar!\com.reissue.automation.stepdefinitions
IntelliJ is able to recognize the Gherkin sentence, but when I run it, it is throwing this exception:
eissueautomationstepdefinitions'
at io.cucumber.core.options.CucumberPropertiesParser.parseAll(CucumberPropertiesParser.java:156)
at io.cucumber.core.options.CucumberPropertiesParser.parse(CucumberPropertiesParser.java:88)
at io.cucumber.core.cli.Main.run(Main.java:48)
at io.cucumber.core.cli.Main.main(Main.java:33)
Does anybody know what this error means or if it's possible to include glue code from external libraries?
I ended up running the following command to copy my dependencies into the target folder which added it to the classpath.
mvn install dependency:copy-dependencies -DskipTests
Then it picked up the glue no problem.
com.edge.automation
com.reissue.automation.stepdefinitions
If anyone has a better solution feel free to post.
May you add the detailed steps on how you accomplish it?
I tried running
mvn install dependency:copy-dependencies -DskipTests
And then running my maven command for running the test cases and not luck.
If you can add your folder structure and how you put it in the glue code of cucumber runner will be appreciated.
Also cucumber version might help.
Thanks
I am new to gauge testing tool .I have a maven project that consists of specs and step implementations. Mvn package phase does generate a jar file with all the required classes. However I cant figure out how i can run the gauge specs using a Main class in java, such that i can just run the jar file to run the tests. Is this possible?
Unfortunately no, Gauge binary must be installed and available to execute the specs.
As the Gauge binary is not written in java it cannot be bundled in a jar file and invoked from a Main class.
If you'd like to automatically download and use Gauge in a CI/CD environment, try something like https://github.com/maven-download-plugin/maven-download-plugin to download gauge into a convenient location as part of your mvn build itself.
More info about this here
There is a way to do this. You have to package maven and gauge inside the project directory and include them in the jar. In the main method, unzip all files, then run a shell script to export maven and gauge in the project directory to $PATH, then execute mvn gauge:execute as usual. It's a bit of a hack as it extracts everything to the directory in which the jar is located, but it works on RHEL 7 and I haven't managed to find a cleaner method.
I have a Groovy project (using Eclipse) which makes use of several #Grab statements. This works fine on my development machine. However I need to distribute this application including all its dependencies to other machines which don't have any internet connection, i.e. it won't be possible to download the necessary JARs from these machines.
Is there a way to somehow automatically include the dependencies into the project, e.g. a lib folder? This way I could just copy the project to another machine and use it.
So, lets say for example you have a script Script.groovy like so, that you currently run with groovy Script.groovy:
#Grab('com.github.groovy-wslite:groovy-wslite:1.1.2')
import wslite.rest.*
def client = new RESTClient("http://httpbin.org")
def response = client.get(path:'/get')
assert 200 == response.statusCode
println "Received : $response.json"
Now, we want to get this into a jar file that you can distribute, and people can just run with java -jar myApp.jar
So make the following folder structure:
myApp
|-- src
| |-- main
| |-- groovy
| |-- example
| |-- Script.groovy
|-- build.gradle
Then, in Script.groovy, put your script (with a package name, and no #Grab annotation):
package example
import wslite.rest.*
def client = new RESTClient("http://httpbin.org")
def response = client.get(path:'/get')
assert 200 == response.statusCode
println "Received : $response.json"
And in build.gradle, put this script which pulls down the groovy, and groovy-wslite dependencies, and applies the shadow-jar plugin to bundle all dependencies into one single fat jar:
plugins {
id "com.github.johnrengelman.shadow" version "1.2.2"
}
apply plugin: 'groovy'
apply plugin: 'application'
repositories {
jcenter()
}
mainClassName = 'example.Script'
dependencies {
compile 'org.codehaus.groovy:groovy-all:2.4.5'
compile 'com.github.groovy-wslite:groovy-wslite:1.1.2'
}
You can then (assuming you have installed Gradle), simply run:
gradle shadowJar
Which will compile your code, and put it and all its dependencies into build/libs/myApp-all.jar
So then, you can just run:
java -jar build/libs/myApp-all.jar
And your script should run as before...
You can then distribute this jar file, instead of just the script...
Hope this helps
I would suggest switching to Gradle or some other build tool that downloads the dependencies at build time. As you probably already know grape pulls down all the dependencies at runtime.
Grape (The Groovy Adaptable Packaging Engine or Groovy Advanced Packaging Engine) is the infrastructure enabling the grab() calls in Groovy, a set of classes leveraging Ivy to allow for a repository driven module system for Groovy. This allows a developer to write a script with an essentially arbitrary library requirement, and ship just the script. Grape will, at runtime, download as needed and link the named libraries and all dependencies forming a transitive closure when the script is run from existing repositories such as Ibiblio, Codehaus, and java.net.
This link might help you in your transition to using Gradle with your Groovy script.
Running Groovy scripts from Gradle
You could copy your Grape repo to the target deployment servers. Should be ~/.groovy/Grape. Then you can keep your #Grabs in the scripts as is
Two solutions
Replace the whole build progress with gradle, just like what's mentioned by #tim_yates' answer.
Use grape install command to pre-install the packages into the grape local repo, whose default path is "~/.groovy/grapes".Then package the scripts and the grape dir together. You might switch the grape repo dir to somewhere you prefer. See section 3.5 of http://docs.groovy-lang.org/latest/html/documentation/grape.html
I am struggling around a wrong usage of composer, for sure.
I set up this repository: https://github.com/alle/assets-merger
I forked the project and was just trying to make it a kohana-module, including all the dependencies.
As for it would need the YUI comporess JAR, I was trying to make just that JARfile as a dependency, and I ended to declare it in the composer.json file (please, look at this).
Once I need to add my new package to a project I add it in the require section as follows:
...
"alle/assets-merger": "dev-master",
...
But the (latest) composer update command says:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for alle/assets-merger dev-develop -> satisfiable by alle/assets-merger[dev-develop].
- alle/assets-merger dev-develop requires yui/yuicompressor 2.4.8 -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
And my story ends here.
How should I configure my composer.json in the https://github.com/alle/assets-merger repository, in order to include it as a fully satisfied kohana-module in other projects?
Some things I notice in your composer.json.
There is a version of that CSS minify available on Packagist which says it is just a copy of the original Goole-Code hosted files, but with Composer: natxet/cssmin. It is version 3.0.2, but I think that shouldn't make a difference.
mrclay/minify is included twice in the packages with the same version. It also is available on Packagist. You will probably already use that (version 2.2.0 is registered, and because you didn't turn of Packagist access, it will be generally available for install unless a version requirement or conflict prevents it).
You are trying to download a JAR file (which is a java executable without and PHP), but try to get PHP classmaps out of it. That will fail for sure.
You did miss the big note in the Composer documentation saying that Composer cannot resolve repositories mentioned in sub packages, only in the root package. That means that whatever you mention in your alle/asset-merger package will not be used if you use that package anywhere else. You'd have to duplicate these repositories in every package in addition to adding the package name itself as "required".
What this means is that you probably avoided missing mrclay/minify because it is available on Packagist, you might as well have added the cssmin by accident, but you definitly did not add YUICompressor.
But you shouldn't add this in the first place, because it is no PHP software. You can however add post-install commands to your projects. All your Composer integration does is download the JAR file. You can do that with a post-install or post-update command. See the documentation here.
1. Generally, how is #Grape/#Grab inclusion different than classpath inclusion?
2. Specifically, what might cause the following behavior difference?
I've got a requirement on xpp3 which I express as:
// TestScript.groovy
#Grab(group='xpp3', module='xpp3', version='1.1.3.4.O')
import org.xmlpull.v1.XmlPullParserFactory;
println "Created: " + XmlPullParserFactory.newInstance()
Running $ groovy TestScript.groovy fails with
Caught: org.xmlpull.v1.XmlPullParserException: caused by: org.xmlpull.v1.XmlPullParserException:
If, however, I manually add the .jar fetched by Grape to my Groovy classpath:
$ groovy -cp ~/.groovy/grapes/xpp3/xpp3/jars/xpp3-1.1.3.4.O.jar \
TestScript.groovy
... then everything works.
Grab uses ivy to fetch the specified library (plus all of its dependencies) from the maven core repository. It then adds these downloaded libraries to the classpath of the loader that's running the current script.
Adding the jar to the classpath just adds the specified jar to the system classpath.
As there are no dependencies in this example, it's probably a requirement that the library needs to be loaded by the system classloader.
To check this, try adding
#GrabConfig(systemClassLoader= true)
#Grab(group='xpp3', module='xpp3', version='1.1.3.4.O')
Instead of the one line Grab you currently have