Lab: Building with Gradle

Steven J Zeil

Last modified: Dec 21, 2019

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

  1. Copy the source code from your unit testing assignment, including both the instructor-provided code and your own unit tests, into a convenient directory.

  2. Create a new Eclipse Java project at that directory. Remember to add the JUnit library to the build path of the new project.

  3. 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.className must be stored as .../packageName1/packageName2/, where the “…” is the directory that serves as the common root of all of your source code.

  4. Your project should include at least one unit test. Right-click on the .java file 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

Now we’ll look at restructuring a project to meet these guidelines.

  1. 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/main/java and src/test/java directories. Move your non-test Java files to src/main/java and move your Unit test Java files to src/test/java.

    • Remember that, in Java, package structure must match directory structure. So if your Java project includes a class MyClass in package cs330.asst1, then you should currently have it in a location cs330/asst1/ When moving your code to the src/main/java and src/test/java directories, you need to keep that whole directory structure. In this example, you would wind up with src/main/java/cs330/asst1/

  2. 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.

  3. We need to tell Eclipse about our intentions to keep our source code in src/main/java and 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/main/java and 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.

  4. 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:

  1. Download and unpack this zip file in your project directory.

  2. Use a text editor to create settings.gradle and build.gradle files mirroring the simple Java build

  3. Check the build by asking for some basic information:

    ./gradlew tasks --all

    (For Windows, omit the “./”).

  4. Try running the actual build from the command line:

    ./gradlew build

    (For Windows, omit the “./”).

    Look through the build/ directory to see what was done.

  5. Enter Eclipse, and delete your project from Eclipse (but do not delete the files).

  6. Back in the command line, delete the files .project and .classpath.

    (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”.)

  7. 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.

    For the gradle version, indicate that you are using the gradle wrapper.

    Once you indicate that you are finished with the varios project settings, Eclipse will examine your settings.gradle and build.gradle files 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 build.grade file.

  8. 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 .java file.
    • 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.

  9. 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 src/main/java and src/test/java directories.

    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.
  10. Now try launching your project build from the Gradle Tasks tab in the lower central panel.

  11. 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 build directory 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”.

  12. 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 Open with... then System Editor, as most systems will define the system “editor” for HTML files as your default web browser.

  13. 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 .jar file. (Hint: Gradle builds everything somewhere within the build/ directory.)

    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.)