Learn how to build and test a simple web application using Gradle and Open Liberty.

You will learn how to build and test a simple web servlet application using the Gradle war plug-in and the Liberty Gradle plug-in. The war plug-in compiles and builds the application code. The liberty Gradle plug-in installs the Open Liberty runtime, creates a server, and installs the application to run and test. The application displays a simple web page with a link. When you click that link, the application calls the servlet to return a simple response of Hello! Is Gradle working for you?.

One benefit of using a build tool like Gradle is that you can define the details of the project and any dependencies it has, and Gradle automatically downloads and installs the dependencies. Another benefit of using Gradle is that it can run repeatable, automated tests on the application. You can, of course, test your application manually by starting a server and pointing a web browser at the application URL. However, automated tests are a much better approach because you can easily rerun the same tests each time the application is built. If the tests don’t pass after you change the application, the build fails, and you know that you introduced a regression that requires a fix to your code.

Choosing a build tool often comes down to personal or organizational preference, but you might choose to use Gradle for several reasons. Gradle defines its builds by using Groovy build scripts, which gives you a lot of control and customization in your builds. Gradle also uses a build cache that rebuilds only the parts of your application that changed, which saves build time in larger projects. So Gradle can be a good choice in larger, more complex projects.

Using this guide, you will create a Gradle build definition file (build.gradle) for the web application project, and use it to build the application. You will then create a simple, automated test, and configure Gradle to run it after building the application.

Learn more about Gradle on the official Gradle website.

https://raw.githubusercontent.com/OpenLiberty/guides-common/prod/gitclone.adoc

The web application that you will build using Gradle and Open Liberty is provided for you in the start directory so that you can focus on learning about Gradle. The application uses the standard Gradle directory structure. Using this directory structure saves you from customizing the build.gradle file later.

All the application source code, including the Open Liberty server configuration (server.xml), is in the start/src directory:

If you do not have Gradle installed, make sure that the JAVA_HOME environment variable is set, or that the Java application can run. Running the Gradle Wrapper automatically installs Gradle. To learn more about the Gradle Wrapper, see the Gradle Wrapper documentation.

Run the following commands to navigate to the start directory and verify that Gradle was installed correctly:

https://raw.githubusercontent.com/OpenLiberty/guides-common/prod/os-tabs.adoc

You should see information about the Gradle installation similar to this example:

You can also view the default tasks available by running the following command:

https://raw.githubusercontent.com/OpenLiberty/guides-common/prod/os-tabs.adoc

settings.gradle

build.gradle

The project configuration is defined in the Gradle settings and build files. You will create these project configurations one section at a time.

Gradle settings are used to instantiate and configure the project. This sample uses the settings.gradle to name the project GradleSample.

This settings.gradle file isn’t required for a single-module Gradle project. Without this definition, by default, the project name is set as the name of the folder in which it is contained (start for this example).

Let’s go through the build.gradle file so that you understand each part.

The first section of code defines the war and liberty plug-ins that you want to use. The war plug-in contains all the tasks to compile Java files, build the WAR file structure, and assemble the archive. The liberty plug-in contains the tasks used to install the Liberty runtime and create and manage servers. The compatibility and encoding settings are for Java.

The buildscript section defines plug-in versions to use in the build and where to find them. This guide uses the liberty plug-in, which is available from the Maven Central Repository.

The repositories section defines where to find the dependencies that you are using in the build. For this build, everything you need is in Maven Central.

The dependencies section defines what is needed to compile and test the code. This section also defines how to run the application. The providedCompile dependencies are APIs that are needed to compile the application, but they do not need to be packaged with the application because Open Liberty provides their implementation at run time. The testImplementation dependencies are needed to compile and run tests.

The Gradle extra properties extension allows you to add properties to a Gradle project. If you use a value more than once in your build file, you can simplify updates by defining it as a variable here and referring to the variable later in the build file. This project defines variables for the application ports and the context-root.

Start Open Liberty in development mode, which starts the Open Liberty server and listens for file changes:

After you see the following message, your application server in development mode is ready.

The development mode holds your command prompt to listen for file changes. You need to open another command prompt to continue, or simply open the project in your editor.

Navigate your browser to the http://localhost:9080/GradleSample/servlet URL to access the application. The servlet returns a simple response of Hello! Is Gradle working for you?.

EndpointIT.java

build.gradle

HelloServlet.java

One of the benefits of building an application with a build system like Gradle is that it can be configured to run a set of automated tests. The war plug-in extends the Java plug-in, which provides test tasks. You can write tests for the individual units of code outside of a running application server (unit tests), or you can write them to call the application that runs on the server (integration tests). In this example, you will create a simple integration test that checks that the web page opens and that the correct response is returned when the link is clicked.

The test class name ends in IT to indicate that it contains an integration test. The integration tests are put in the it folder by convention.

The test section in your build file is added by the Java plug-in, and the useJUnitPlatform() line configures Gradle to add JUnit 5 support.

The systemProperty configuration defines some variables needed by the test class. While the port number and context-root information can be hardcoded in the test class, it is better to specify it in a single place like the Gradle build.gradle file, in case they need to change. The systemProperty lines passes these details to the test JVMs as a series of system properties, resolving the http.port and context.root variables.

The init() method in the EndpointIT.java test class uses these system variables to build the URL of the application.

In the test class, after defining how to build the application URL, the @Test annotation indicates the start of the test method.

In the try block of the test method, an HTTP GET request to the URL of the application returns a status code. If the response to the request includes the string Hello! Is Gradle working for you?, the test passes. If that string is not in the response, the test fails. The HTTP client then disconnects from the application.

In the import statements of this test class, you’ll notice that the test has some new dependencies. Earlier you added some testImplementation dependencies. The Apache commons-httpclient and org.junit.jupiter dependencies are needed to compile and run the integration test EndpointIT class.

The scope for each of the dependencies is set to testImplementation because the libraries are needed only during the Gradle test phase and do not need to be packaged with the application.

Now, the created WAR file contains the web application, and development mode can run any integration test classes that it finds. Integration test classes are classes with names that end in IT.

The directory structure of the project in the start folder should now look like this example:

A few more pieces

Running the tests

You built and tested a web application project running on an Open Liberty server using Gradle.

https://raw.githubusercontent.com/OpenLiberty/guides-common/prod/attribution.adoc