By Alex LaFroscia and Will Engler
-
Mac OSX
brew install gradle
If you need to install Homebrew (which gives you the
brew
command) you can find out more about it here. -
Ubuntu
sudo add-apt-repository ppa:cwchien/gradle sudo apt-get update sudo apt-get install gradle
$ cd path/to/your/project
$ echo ".gradle/" >> .gitignore
$ echo "build/" >> .gitignore
$ gradle init
Gradle expects your .java
files to be in src/main/java
, so for CoffeeMakerQuest you'll need to do something like this:
mkdir -p src/main/java
mv *.java src/main/java
This allows Gradle to find the right files when it's trying to build your .jar
file.
This is where Gradle will find most of its configuration information. The default one is a good starting place. The one I'm using is attached.
One thing you have to make sure you do is tell Gradle where your main()
method is. For CoffeeMakerQuest, that looks like this:
jar {
manifest {
attribute 'Main-Class': 'com.laboon.CoffeeMaker'
}
}
Gradle looks for tests in src/test/java
. You can link against JUnit or Mockito like you noramally would, if they were in your classPath
, using
import static org.junit.Assert.*;
import org.junit.*;
etc.
$ gradle build
Outputs a .jar
file to build/lib
$ gradle test
Runs JUnit tests on your code (by default). Outputs an HTML file with test results to build/reports/tests/index.html
.
$ gradle jacoco
Outputs a code coverage report to build/reports/jacoco/test/html/index.html
. The path is obnixous, but at least it works.
Note about running Gradle commands: Sometimes the commands need to do some initial setup (installing dependencies, etc) the first time they are run. I had a lot of trouble getting JaCoCo to work initially because it couldn't find the JaCoCo executable. Two things have I've found helpful are:
-
Running Gradle through the
gradlew
wrapper script that is generated by the initial setup command (see step 1 above)It seems like sometimes this will download dependencies that are not downloaded if you just use
gradle
. If anyone knows more about this, please comment below and I'll update this guide.An example of running a command with the wrapper would be doing
$ ./gradlew test
instead of
$ gradle test
The wrapper will always work, even if you're not having trouble.
-
Destroy your
build/
directoryThis is fine because all of the files are generated by the Gradle commands. If you notice in step 1 above, we don't even keep the
build/
directory under source control. I found with JaCoCo that it assumed the executable existed becausebuild/
existed, even though it hadn't been downloaded yet. Deleting it and starting again without abuild/
directory got things working right.
- Try running with the "wrapper" (
./gradlew
instead ofgradle
) - Try deleting the
build/
directory
- Code Coverage in Test Report
- Don't have Syntastic/other linters show errors all over the tests