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
Related
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.
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
how to export a executable jar in gradle, and this jar can run as it include reference libraries.
build.gradle
apply plugin: 'java'
manifest.mainAttributes("Main-Class" : "com.botwave.analysis.LogAnalyzer")
repositories {
mavenCentral()
}
dependencies {
compile (
'commons-codec:commons-codec:1.6',
'commons-logging:commons-logging:1.1.1',
'org.apache.httpcomponents:httpclient:4.2.1',
'org.apache.httpcomponents:httpclient:4.2.1',
'org.apache.httpcomponents:httpcore:4.2.1',
'org.apache.httpcomponents:httpmime:4.2.1',
'ch.qos.logback:logback-classic:1.0.6',
'ch.qos.logback:logback-core:1.0.6',
'org.slf4j:slf4j-api:1.6.0',
'junit:junit:4.+'
)
}
after i run : gradle build
it create the build folder, and i run the jar in build/libs/XXX.jar:
java -jar build/libs/XXX.jar
here is a execution says :
Exception in thread "main" java.lang.NoClassDefFoundError: ch/qos/logback/core/joran/spi/JoranException
how can i run it with the reference libraries?
You can achieve it with Gradle application plugin
Hopefully this helps someone (as I unfortunately spent quite some time trying to find the solution). Here's the solution that worked for me for creating an executable JAR. I'm embedding Jetty in the main method, Jetty 9 to be specific and using Gradle 2.1.
Include the following code into your build.gradle file (if a subproject is the "main" project that the jar needs to be built from, then add it to the subproject which should start like this project(':') { insert the code somewhere here, after dependencies.}.
Also, you need to add the plugin java for this to work: apply plugin: 'java' .
My jar task looks as follows:
apply plugin: 'java'
jar {
archiveName = "yourjar.jar"
from {
configurations.runtime.collect {
it.isDirectory() ? it : zipTree(it)
}
configurations.compile.collect {
it.isDirectory() ? it : zipTree(it)
}
}
manifest {
attributes 'Main-Class': 'your.package.name.Mainclassname'
}
exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
}
And then you can execute your yourjar.jar via the commandline:
java -jar yourjar.jar
The META-INF/.RSA, META-INF/.SF and META-INF/*.DSA have to be excluded for it to work. Otherwise a SecurityException gets thrown.
The problem seems to lie with embedded Jetty, as Jetty moved to Eclipse and now is signing their JARs, which I read becomes problematic when other, unsigned JARs want to load the signed ones. Please feel free to educate me if I am wrong in this, that's just what I read.
The JARs that the project depends on are defined in the dependencies as follows:
dependencies {
// add the subprojects / modules that this depends on
compile project(':subproject-1')
compile project(':subproject-2')
compile group: 'org.eclipse.jetty', name: 'jetty-server', version: '9.2.6.v20141205'
compile group: 'org.eclipse.jetty', name: 'jetty-servlet', version: '9.2.6.v20141205'
compile group: 'org.eclipse.jetty', name: 'jetty-http', version: '9.2.6.v20141205'
}
EDIT: Before, instead of just
configurations.runtime.collect{...}
i had
configurations.runtime.asFileTree.files.collect{...}
This caused strange behaviour in a larger project in clean build. When running the jar after executing gradle clean build for the first time (after manually cleaning the build directory), it would throw a NoClassDefFoundException (in our project with many subprojects), but running the jar after executing gradle clean build a second time (without emptying the build directory manually), for some reason it had all dependencies. This didn't happen if asFileTree.files was left out.
Also I should note, all compile dependencies are included in runtime, however not all runtime are included in compile. So if you are just using compile
configurations.compile.collect {
it.isDirectory() ? it : zipTree(it)
}
Then be sure to remember that if there is a NoClassDefFoundException thrown, some class isn't found at runtime, which means you should also include this:
configurations.runtime.collect {
it.isDirectory() ? it : zipTree(it)
}
Quick answer
Add the following to your build.gradle:
apply plugin: 'application'
mainClassName = 'org.example.app.MainClass'
jar {
manifest {
attributes 'Main-Class': mainClassName,
'Class-Path': configurations.runtime.files.collect {"$it.name"}.join(' ')
}
}
From the project directory, run gradle installDist
Run java -jar build/install/<appname>/lib/<appname>.jar
I recommend adding the app version to your build.gradle as well, but it's not required. If you do, the built jar name will be <appname>-<version>.jar.
Note: I'm using gradle 2.5
Details
In order to create a self contained executable jar that you can simply run with:
java -jar appname.jar
you will need:
your jar to include a MANIFEST file pointing to your application main class
all your dependencies (classes from jars outside of your application) to be included or accessible somehow
your MANIFEST file to include the correct classpath
As some other answers point out, you can use some third-party plugin to achieve this, such as shadow or one-jar.
I tried shadow, but didn't like the fact that all my dependencies and their resources were dumped flat out into the built jar together with my application code. I also prefer to minimize the use of external plugins.
Another option would be to use the gradle application plugin as #erdi answered above. Running gradle build will build a jar for you and nicely bundle it with all your dependencies in a zip/tar file. You can also just run gradle installDist to skip zipping.
However, as #jeremyjjbrown wrote in a comment there, the plugin does not create an executable jar per se. It creates a jar and a script which constructs the classpath and executes a command to run the main class of your app. You will not be able to run java -jar appname.jar.
To get the best of both worlds, follow the steps above which create your jar together with all your dependencies as separate jars and add the correct values to your MANIEST.
All of these answers are either wrong or out of date.
The OP is asking for what is known as a "fat jar". That is an exectuable jar which contains all the dependencies so that it requires no outside dependencies in order to run (except for a JRE of course!).
The answer at the time of writing is the Gradle Shadow Jar plugin, explained pretty clearly at Shadow Plugin User Guide & Examples.
I struggled a bit. But this works:
put all these lines somewhere in your build.gradle file (I put them near the top) :
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.github.jengelman.gradle.plugins:shadow:1.2.4'
}
}
apply plugin: 'com.github.johnrengelman.shadow'
shadowJar {
baseName = 'shadow'
classifier = null
version = null
}
jar {
manifest {
attributes 'Class-Path': '/libs/a.jar'
attributes 'Main-Class': 'core.MyClassContainingMainMethod'
}
}
PS don't worry about any other "repositories", "dependency" or "plugin" lines elsewhere in your build file, and do leave the lines thus inside this "buildscript" block (I haven't a clue why you need to do that).
PPS the Shadow Plugin User Guide & Examples is well-written but doesn't tell you
to include the line
attributes 'Main-Class': 'core.MyClassContainingMainMethod'
where I've put it above. Perhaps because the author assumes you are less clueless than I am, and you probably are. I haven't a clue why we are told to put a strange "Class-Path" attribute like that in, but if it ain't broke don't fix it.
When you then go
> gradle shadowjar
Gradle will hopefully build a fat executable jar under /build/libs (default name "shadow.jar") which you can run by doing this:
> java -jar shadow.jar
I checked quite some links for the solution, finally did the below mentioned steps to get it working. I am using Gradle 2.9.
Make the following changes in your build,gradle file :
1. Mention plugin:
apply plugin: 'eu.appsatori.fatjar'
2. Provide the Buildscript:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath "eu.appsatori:gradle-fatjar-plugin:0.3"
}
}
3. Provide the Main Class:
fatJar {
classifier 'fat'
manifest {
attributes 'Main-Class': 'my.project.core.MyMainClass'
}
exclude 'META-INF/*.DSA', 'META-INF/*.RSA', 'META-INF/*.SF'
}
4. Create the fatjar:
./gradlew clean fatjar
5. Run the fatjar from /build/libs/ :
java -jar MyFatJar.jar
Is there any way to access Gradle groovy plugin sourceSets dirs from my Groovy project built by Gradle? I am looking for default gradle src and resources directories.
I need it to avoid hardcoding a resources directory in my project but use the default Groovy plugin resource directory (resources/main).
You shouldn't mix up your production code with your test sources and your test resources. I would suggest the following layout (the default of the groovy plugin) of your src directories in your project:
groovy production code in "src/main/groovy"
unit tests written in java or groovy in "src/test/groovy"
*.groovy resources for testing your DSL in "src/test/resources"
Now you can reference the .groovy dsl test files from your tests via
URL url = this.getClass().getResource("/testDsl.groovy");
File testDslFile = new File(url.getFile());
Can you explain the use case for that? within your gradle build you can access the groovy sourceSets dirs introduced by Gradles groovy plugin like this:
apply plugin:'groovy'
task printGroovySourceDirs << {
sourceSets.main.groovy.srcDirs.each{
println it.absolutePath
}
}
I try to run my first Spock Test inside Eclipse, and it does not work.
I added all the Maven dependencies and plugins in my pom.xml, but when I run my test with jUnit, there is a popup windows with this Warning message : "No jUnit tests found".
Did you already seen this kind of message ?
What config has to be done, in order to run a Spock Test inside Eclipse ?
Thanks a lot.
Its same as running Junit test cases.
Right click on the class and run as 4Junit Test runner. see below for complete configurations and running the spock test.
Running Spock Framework with Eclipse, Gradle, Groovy: Source -
Krzysztof Goralski, blog
-Install Gradle Plugin, check it here
-Install Groovy-Eclipse for Juno or Indigo from Eclipse Marketplace (or maybe Groovy/Grails Tool Suite for Eclipse)
-Install Spock Plugin From Eclipse Marketplace if you want, check it here
-Import Project to Eclipse through Gradle Import
-Add these lines to build.gradle:
apply plugin: ‘groovy’
testCompile ‘org.spockframework:spock-spring:1.0-groovy-2.3’ (for Spring)
this is quite important, version can make some conflicts
-After this *.groovy and *.gradle files will problably looks different, Syntax colour highlightning etc. Remember that you can right click on for eg. build.gradle -> Open with -> Open With Minimalist gradle Editor etc.
-Probably you will need to make additional folder for *.groovy test files
Create new *.groovy file, class
-Basic test example, extends Specification from Spock framework and needs specific Annotations when running with Spring
-Now you can run it with JUnit from Eclipse
For integration tests you can’t use #RunWith(SpringJUnit4ClassRunner.class), and Context should looks like here #ContextConfiguration(locations = [ “/restTestContext.xml” ]) , not {} braces, but [ ]
-Spock can be used for Mocks too. Something like this: Subscriber subscriber1 = Mock() , subscriber1.isActive() >> true , So, remember >> operator for mocks.
Right click on the project > Properties > Java Build Bath > Add External Jars and add spock-core-0.6-groovy-1.8.jar and check if Groovy Libraries are there in Build Path or not. If not click on Add Library and select Groovy Runtime Libraries and restart Eclipse. Now you should be able to run. If still can't Run then try creating New Configuration and change the Test runner to Junit4 and Run it...
Check if the folder your tests are in is a source folder.