Lab: Building with Gradle
Steven J Zeil
This is a self-assessment activity to give you practice in working with the
ant build manager. Feel free to share your problems, experiences, and choices in the Forum.
1 Find That Project
In your assignment for the Unit Testing section of the course, you have been working with an ADT and accompanying tests.
We’ll use that code as a starting point for this lab. (If, for some reason, you don’t have working code for that assignment, you can use your project from this earlier lab, but those tests were not very interesting.)
2 Compiling and Cleaning Up
Copy the source code from your unit testing assignment, including both the instructor-provided code and your own unit tests, into a convenient directory.
Create a new Eclipse Java project at that directory. Remember to add the JUnit library to the build path of the new project.
Your code should compile under Eclipse to start with.
If your code was compiling but you have problem with this copied code, remember that a class
packageName1.packageName2.classNamemust be stored as
.../packageName1/packageName2/className.java, where the “…” is the directory that serves as the common root of all of your source code.
Your project should include at least one unit test. Right-click on the
.javafile for such a test and select “Run As… JUnit test” to be sure that your tests run.
3 Restructuring Your Project
In the lectures we talked about conventional ways of organizing the files that make up a project, including the Apache Foundation’s organization for Java projects.
Some important characteristics of this organization are
- All the “source” files (code and data) written by the developers go into a
- All the files generated by the build process go into a
srcdirectory is divided into
- Files generated from
src/mainare assumed to become part of the final deliverable.
- Files generated from
src/testare used during testing, but not included in the final deliverable.
- Files generated from
src/testdirectories are further divided according to programming language and/or “type” of data. Common subdirectories are
At a minimum, an Apache-style Java project should expect to have
Now we’ll look at restructuring a project to meet these guidelines.
Do this outside of Eclipse using normal operating system commands (command-line or GUI): Go to the directory holding your project. (If you aren’t sure where that is, right-click on the project name in Eclipse, select Properties, and look at the Resource description.) Create
src/test/javadirectories. Move your non-test Java files to
src/main/javaand move your Unit test Java files to
Remember that, in Java, package structure must match directory structure. So if your Java project includes a class
cs330.asst1, then you should currently have it in a location
cs330/asst1/MyClass.java. When moving your code to the
src/test/javadirectories, you need to keep that whole directory structure. In this example, you would wind up with
Return to Eclipse, right-click on your project name, and select “Refresh”. Eclipse will discover your new directory structure, but won’t know what to make of it. You’ll almost certainly wind up with error messages suggesting that your classes are in the wrong packages.
We need to tell Eclipse about our intentions to keep our source code in
src/test/java. The key to doing that is the project Build Path.
Right-click on any file of your project and select “Build path => Configure Build Path”. Go to the Source tab. This is where we tell Eclipse where to look for Java source code. Add the folders
src/test/java, then remove whatever folders had been listed previously.
Click OK and, within a few seconds, you should see those error messages disappear.
One nice thing about adopting a standard project directory organization is that build files for that organization tend to be pretty similar. You can often re-use build files from one Apache-style project for another.
4 Building with Gradle
Do these steps from the command line, not in Eclipse:
Download and unpack this zip file in your project directory.
Use a text editor to create
build.gradlefiles mirroring the simple Java build
Check the build by asking for some basic information:
./gradlew tasks --all
(For Windows, omit the “./”).
Try running the actual build from the command line:
(For Windows, omit the “./”).
Look through the
build/directory to see what was done.
Enter Eclipse, and delete your project from Eclipse (but do not delete the files).
Back in the command line, delete the files
(These are the Eclipse project settings from our earlier work with this directory. Since we are about to re-use this directory for a very different Eclipse setup, it’s safer to start “fresh”.)
Right-click in the Eclipse Project Explorer area, and select “Import…”, Gradle, Gradle Project, and point it at the directory where your project was located.
gradleversion, indicate that you are using the gradle wrapper.
Once you indicate that you are finished with the varios project settings, Eclipse will examine your
build.gradlefiles and configure its own settings accordingly. There may be a bit of a pause while Eclipse loads up-to-date versions of any third-party libraries (e.g., JUnit and Hamcrest) listed in your
You should still be able to work in Eclipse and
- edit your source code, getting instant response to many errors as you type.
- see your project rebuild whenever you save a changed
- be able to run the Java program and your unit tests.
Try making some small changes to the code and verify that everything still works from Eclipse as normal.
Right-click on the project name, select “Build Path … Configure Build Path”.
Examine the source directories that have been set up. You should see that Eclipse/Gradle have recognized your
Look at the Libraries tab. You should see a library “Project and External Dependencies”. Expanding that will show you libraries that Eclipse/Gradle have downloaded and incorporated into your project.
- We’ll talk more about how that happens in an upcoming lesson.
Now try launching your project build from the Gradle Tasks tab in the lower central panel.
One oddity that you might notice if you look at your project directory using the operating system is that you have two sets of compiled class paths, one in
bin/(caused by Eclipse compilation) and another in
build/(caused by Gradle compilations). It’s possible to force Eclipse to use
build/as well, but probably not worth the effort.
Oddly, though, you probably can’t see the
builddirectory in Eclipse because the Eclipse Project Explorer has several selective “filters” that it applies before deciding what to show you.
Let’s change these filters so that you can see stuff that’s important.
At the top of the Project Explorer pane, look for a small triangle indicating a drop-down menu. Click on it and select “Filters …”
Remove the check marks from “.* resources” and from “Gradle Build Folder”.
Now that you can actually see your
build/folder, browse through it. Among other things, you should see a report generated that summarizes the unit tests that you have run.
Try reading that report.
When the Eclipse Project Explorer is showing you an HTML file, you can usually view it by right-clicking on the file and seelecting
System Editor, as most systems will define the system “editor” for HTML files as your default web browser.
You have now practiced running Gradle from the command line and from within Eclipse. You can use either as you prefer.
Remember, however, that whenever you use programs or commands outside of Eclipse to make changes to the project directory, you need to refresh your Eclipse project when you return to Eclipse. (Right-click on the project name and select “Refresh”.)
It’s often convenient to run Gradle from within Eclipse to do things not supported by or not so easy to do directly in Eclipse.
Try running the Gradle task “jar” within Eclipse. Refresh Can you find the generated
.jarfile. (Hint: Gradle builds everything somewhere within the
Now try running the Gradle
javadoctask within Eclipse. Find the newly generated HTML and browse it. (We’ll talk more about Javadoc in coming weeks.)