Gradle Building Java Web applications

Transferred from: http://www.blogjava.net/jiangshachina/archive/2014/02/03/409285.html

This article is an excerpt from <gradle in Action>, published on Java.net, that describes the process of building a Java Web application using Gradle. Just contact Gradle, see this small article, readily translated out:-) (Last updated 2014.01.23)

In today's world, there is a rush. In our career and private life, many of us have to manage multiple projects at the same time. You may often find yourself in a state of confusion and loss of control. The key to keeping it regular and focused on value is a well-maintained work list. Of course, you may always write your task on a piece of paper, but you may not be able to get these work items easily anywhere in your area. Access to the Internet is almost ubiquitous, whether it's through your mobile phone or a public network access point. In the <gradle in action> book, the illustrative example shown in 1 is an attractive Visual Web application.

Figure 1 The To do app can be accessed over the Internet and used to manage work items in the data store

The Gradle plug-in behaves like an enabling device, which performs these tasks automatically. A plug-in extends the project by introducing specific domain specifications and tasks that are sensitive to default values. One of the plugins released with Gradle is the Java plugin. The Java plugin is more than just a basic feature that provides the source code for compiling and packaging. It establishes a set of standard catalog layouts for the project, which ensures that tasks are performed in the correct order, so that these tasks are meaningful in the Java engineering environment. Now is the time to create a build script for our app and to use this Java plugin.

Building Java Applications
At first, each Gradle project creates a build script called Build.gradle. In order to create the script and tell the project to use the Java plugin, you should do it like this:

Apply plugin: ' java '

To build your Java code, one line of code is enough. But how does Gradle know where to find your source file? One of the specifications introduced by the Java plugin is the path to the source code. By default, the plugin searches the catalog Src/main/java for the source code of the product.

Building Web Apps
With the war plug-in, Gradle also provides extended support for building Web applications. The war plug-in extends the Java plug-in, joins the specification for Web application development, and supports the imputation of war files. Let's also use the war plugin in this project:

Apply plugin: ' War '

The default path for Web App source files is Src/main/webapp. Suppose you have defined the Java classes necessary for the application. Then to make the full source code and Web resource files for the product in the correct path, the catalog layout for the project should look like this:

.
├──build.gradle
└──src
└──main
├──java
│└──com
│└──manning
│└──gia
│└──todo
│├──model
││└──todoitem.java
│├──repository
││├──inmemorytodorepository.java
││└──todorepository.java
│└──web
│└──todoservlet.java
└──webapp #A
├──web-inf
│└──web.xml #B
├──css #C
│├──base.css
│└──bg.png
└──jsp #D
├──index.jsp
└──todo-list.jsp

#A Web source file default directory
#B Web App Descriptor file
#C a directory that stores style sheets that describe how HTML elements are presented
#D dynamic scripted view components in JSP form

Declaring external dependencies
In the process of implementing this Web application, some of the classes we use, such as Javax.servlet.HttpServlet, are not part of Java Standard Edition (Java SE). Before building the project, we need to make sure that these external dependencies have been declared. In a Java system, a dependent class library is published and used in the form of a jar file. Many class libraries can be obtained from warehouses, such as a file system or a central server. To use dependencies, Gradle requires you to define at least one warehouse. For some consideration, we will use the common MAVEN central repository, which is accessible via the Internet.

repositories {
Mavencentral () #A
}
#A access to Maven2 Central Warehouse by Http://repo1.maven.org/maven2 short Mark

In Gradle, dependencies are grouped by configuration items. Our future servlet relies on the configuration item that is Providedcompile. This configuration item is used for dependencies that are required at compile time and not at runtime. Run-time dependencies like Jstl are not used at compile time, but are used at run time. They all become part of the war file. The following configuration statement block declares the external class libraries that we need to apply:

dependencies {
Providedcompile ' javax.servlet:servlet-api:2.5 '
Runtime ' javax.servlet:jstl:1.1.2 '
}

Building projects
We are ready to build this project. Another Java plug-in task in the project is named build. The task compiles the source code, runs the test program, and gathers the war files-all of which are executed in the correct order. After executing the command gradle build, you may get a shape like the following output:

$ gradle Build
: Compilejava #A
:p rocessresources Up-to-date
: Classes
: War #B
: Assemble
: Compiletestjava Up-to-date #C
:p rocesstestresources Up-to-date
: testclasses Up-to-date
: Test #D
: Check
: Build

#A compiling Java source code for the product
#B the task provided by the war plug-in to collect the war file
#C compiling Java Test source code
#D Run Unit Tests

Each line of the above output represents a task performed by a Java or war plug-in. You may notice that some tasks are marked as up-to-date. It means that the task has been skipped. The incremental build support policy of Gradle automatically identifies the work that is not required to be performed. Especially in large commercial projects, this feature can greatly save time.
In the root section of the project, you will find a subdirectory named build that contains all the output after the build is executed, including class files, test reports, a collection of war files, and temporary files that are required for packaging, such as manifest. The following is the structure of the project directory after the build works:

.
├──build
│├──classes
││└──main #A
││└──com
││└──manning
││└──gia
││└──todo
││├──model
│││└──todoitem.class
││├──repository
│││├──inmemorytodorepository.class
│││└──todorepository.class
││└──web
││├──todoservlet$todoliststats.class
││└──todoservlet.class
│├──dependency-cache
│├──libs
││└──todo-webapp.war #B
│├──reports
││└──tests
││├──base-style.css
││├──css3-pie-1.0beta3.htc
││├──index.html
││├──report.js
││└──style.css
│├──test-results
││└──binary
││└──test
││└──results.bin
│└──tmp
│└──war
│└──manifest. MF #C
├──build.gradle
└──src

#A The default directory containing Java class files
#B A collection of war files
#C temporary manifest file for war

You already know how to build a war file from a Web project based on a standard directory structure. Now it's time to put it into a servlet container. In the next section, we will launch jetty in the local development machine to run the Web App.

Run the App
It should be easy to run a Web application on a local machine, be able to practice rapid application development (RAD), and be able to provide fast start-up time. Best of all, it does not require you to deploy a Web container runtime environment. Jetty is a popular lightweight open-source web container that supports all the features mentioned earlier. By adding an HTTP module to this Web application, it becomes an embedded implementation. The Gradle jetty plugin extends the war plug-in, which provides tasks to deploy a Web application to an embedded container and to launch the application. In your build script, you can use this plugin as follows:

Apply plugin: ' Jetty '

This will be the task we use to start the Web app named Jettyrun. It can even start a jetty container without creating a war file. Executing the above command will give you the following form of output:

$ gradle Jettyrun
: Compilejava
:p rocessresources Up-to-date
: Classes
> Building >: Jettyrun > Running at Http://localhost:8080/todo-webapp-jetty

In the last line of the above output, the plug-in tells you the requested address that jetty is about to listen to. Open a browser of your liking and enter the above address. Finally, we'll see the behavior of this to-do web App. Figure 2 shows a screenshot of the app's interface viewed in a browser.

Figure 2 Web interface and its behavior for the to do application

Gradle will keep it running until you stop the app by combining CTRL + C. How does jetty know which port and context to use to run this web app? Again, that's the norm. Jetty the default port used to run the Web app is 8080.

Summarize
With less effort, you can use Gradle to build and run a Java Web application. As long as you strictly follow the standard directory structure, your build script requires only two lines of code.

Gradle Building a Java Web application (GO)