Java Reference
In-Depth Information
private void
callServlet() {
String response = "http://localhost:$httpPort
/HelloServlet/hello"
.
toURL
().
text
.trim()
assert
response == 'Hello, Servlet!'
}
The
intTest
taskisdefinedusingtheleft-shiftoperator(
<<
),whichisanaliasforadding
a
doLast
closure. In other words, this defines the task but doesn't execute it. Because the
task depends on the
jettyRun
task,
jettyRun
will be called first if this task is invoked.
The task calls the private
callServlet
method, which converts a
String
to a URL,
accesses the site, and compares the response to the expected value. Once the method com-
pletes, the
intTest
task tells Jetty to shut down, and I'm finished.
I can invoke the
intTest
task directly from the command line, but I'd rather make it part
of my normal build process. To do that, I notice that in the directed acyclic graph (DAG,
see
chapter 5
) formed by the Gradle build file, the next task after the test task is completed
is called
check
.
Thatsoundedwaymorecomplicatedthanitactuallywas.AllIneededtodowasrunGradle
with the
-m
flag to keep it from actually executing, which gives the following output:
prompt> gradle -m build
:compileJava SKIPPED
:processResources SKIPPED
:classes SKIPPED
:war SKIPPED
:assemble SKIPPED
:compileTestJava SKIPPED
:processTestResources SKIPPED
:testClasses SKIPPED
:test SKIPPED
:check SKIPPED
:build SKIPPED
BUILD SUCCESSFUL
As you can see, the
check
task occurs right after the
test
task completes, and the
in-
tTest
task doesn't execute at all unless I call for it. To put my task into the process, I set
it as a dependency of the
check
task:
check.dependsOn intTest
