1. Java Build Tools
Sujit Kumar
Zenolocity LLC © 2013-2023

2. Manual Development Tasks In Eclipse
•
•
•
•
•
•
•
•
•
Clean Code – remove all your class files
Compile Code
Run your application
Run JUnit tests
Package jars
Package wars
Deploy wars to an application server
**** How do u automate all the above? ***
Batch file on windows or Shell Scripts for Unix
and Mac. Not portable.

3. Available Tools for Automation
•
•
•
•
ANT
Maven
Gradle
All the above (Ant, Maven, Gradle) are
portable options built on top of the JVM.

4. ANT
• Based on XML.
• Tasks to automate nearly everything that you
can do from a shell script or batch file.
• You can even do procedural flow control using
XML.

5. Setting up ANT environment variables
on Windows
• set ANT_HOME=C:Userssujitdevappsapacheant-1.8.2
• set PATH=%ANT_HOME%bin;%PATH%
• Verify ANT version by running:
ant –version
• Ant itself needs JAVA_HOME and JDK_HOME to
be set.

6. Set up environment variables on Unix
• Add the following lines in your ~/.bashrc
• export
ANT_HOME={PATH_TO_PARENT_DIR_OF_ANT
}/apache-ant-1.8.2
• export PATH=$ANT_HOME/bin:$PATH
• Verify ANT version by running:
ant -version

7. ANT Core tasks Categories – Part 1
• Compile Tasks: javac, depend, jspc, apt
• Execution Tasks: ant, antcall, exec, java,
parallel, sequential
• File Tasks: copy, delete, mkdir, move, replace,
touch, chmod, chgrp, concat,
• Mail Tasks: mail
• SCM Tasks: Cvs, Svn, Clearcase, PVCS.
• Testing Tasks: Junit, JUnitReport.

8. ANT Core Task Categories – Part 2
• Property Tasks: Property, LoadProperties,
XMLProperty, Dirname, Basename, Condition,
Uptodate, Available, etc.
• Remote Tasks: ftp, scp, telnet, etc.
• Pre-process Tasks: import, include, etc.
• Miscellaneous Tasks: Echo, Fail, Taskdef,
Typedef, Tstamp, etc.
• Archive Tasks: jar, unjar, war, unwar, zip,
unzip, tar, untar, gzip, gunzip.

9. Flow Control with ANT
• Execute flow control logical tasks like if, for,
foreach, switch, assert, trycatch, etc.
• http://ant-contrib.sourceforge.net/tasks

10. Maven
• Software project management tool. Manage
project’s build, dependencies & documentation.
• Based on the concept of a project object model
(POM).
• Efficient dependency management by using
repositories of dependent jars.
• Extensible with lot of plugins in java.
• Uses the Convention over configuration design
pattern – minimizes code & decision making
without losing flexibility.

11. Simple ANT build.xml file

12. Simple Maven pom.xml file
• <project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>my-project</artifactId>
<version>1.0</version>
• </project>
• See how simple the pom xml file looks like.
• Where Ant had to be explicit about the process, there was
something "built-in" to Maven that just knew where the source
code was and how it should be processed.
• Convention over configuration reduces amount of code and
configuration.

13. Maven Configuration Files
•
•
•
•
•
JAVA_HOME where JDK is installed.
Add JAVA_HOME/bin to the PATH.
M2_HOME where Maven is installed.
Add M2_HOME/bin to the PATH.
2 locations where a settings.xml file may live:
Global: ${M2_HOME}/conf/settings.xml
Local: ${HOME}/.m2/settings.xml
• If both files exist, contents are merged & local
overrides global.

14. Maven Repositories
• Local
• Central
• Remote

15. Local Repository
• Project’s dependent jars are downloaded and
stored in the local repository.
• Default location: {HOME_DIR}/.m2
• Change location of local repository in
{M2_HOME}confsetting.xml, update
localRepository to something else.

16. Maven Build Life Cycle
• Conventional process for building & distributing
an artifact.
• Defined by a list of build phases. A phase is a
stage in the build process.
• 3 built in build life cycles: default, clean & site.
• Build phases are executed sequentially.
• When a build phase is executed, it will execute
not only that build phase, but also every build
phase prior to the called build phase.

17. Default Build Life Cycle
•
•
•
•
•
•
•
•
•
•
•
•
validate: validate the project is correct and all necessary information is available.
initialize: initialize build state, eg. Set properties or create directories.
generate-resources: generate resources for inclusion in the package.
process-resources: copy and process the resources into the destination directory.
compile: compile the source code of the project.
test-compile: compile the test source code of the project.
test: test the compiled source code using a suitable unit testing framework. These
tests should not require the code be packaged or deployed
package: take the compiled code and package it in its distributable format, such as
a JAR.
integration-test: process and deploy the package if necessary into an environment
where integration tests can be run
verify: run any checks to verify the package is valid and meets quality criteria
install: install the package into the local repository, for use as a dependency in
other projects locally
deploy: done in an integration or release environment, copies the final package to
the remote repository for sharing with other developers and projects.

18. Life Cycle Reference
• List in the previous slide not a complete list.
• Full list available here:
• https://maven.apache.org/guides/introductio
n/introduction-to-thelifecycle.html#Lifecycle_Reference

19. Maven Goals & Phases
• Goals are executed in phases which helps determine the order
goals get executed in.
• Compile phase goals will always be executed before the Test phase
goals which will always be executed before the Package phase goals
and so on.
• When you create a plugin execution in your Maven build file and
you only specify the goal then it will bind that goal to a given
default phase. For example, the jaxb:xjc goal binds by default to the
generate-resources phase. However, when you specify the
execution you can also explicitly specify the phase for that goal as
well.
• If you specify a goal when you execute Maven then it will still run all
phases up to the phase for that goal. In other words, if you specify
the jar goal it will run all phases up to the package phase (and all
goals in those phases), and then it will run the jar goal.

20. Differences between ANT and Maven –
part 1
• Ant doesn't have formal conventions like a common
project directory structure. You have to tell Ant exactly
where to find the source and where to put the output.
Informal conventions have emerged over time, but
they haven't been codified into the product.
• Ant is procedural, you have to tell Ant exactly what to
do and when to do it. You had to tell it to compile, then
copy, then compress.
• Ant doesn't have a lifecycle, you have to define goals
and goal dependencies. You have to attach a sequence
of tasks to each goal manually.

21. Differences between ANT and Maven –
part 2
• Maven has conventions, it knows where your source code
is because you followed the convention. It puts the byte
code in target/classes, and it created a JAR file in target.
• Maven is declarative. All you had to do was create a
pom.xml file and put your source in the default directory.
Maven took care of the rest.
• Maven has a lifecycle, which you invoked when you
executed “mvn” install. This command tells Maven to
execute a sequence of steps until it reached the lifecycle.
As a side-effect of this journey through the lifecycle, Maven
executed a number of default plugin goals which did things
like compile and create a JAR.

22. Differences between ANT and Mavenpart 3
• Maven has intelligence about common
project tasks. To run tests, simple execute mvn
test, as long as the files are in the default
location. In Ant, you would first have to
specify the location of the JUnit JAR file, then
create a classpath that includes the JUnit JAR,
then tell Ant where it should look for test
source code, write a goal that compiles the
test source and then finally execute the unit
tests with JUnit.

23. Comparison with Gradle
• http://xpanxionsoftware.wordpress.com/2012
/05/11/ant-maven-and-gradle-a-side-by-sidecomparison/