The document discusses build tools and continuous integration. It provides an overview of Maven, a build tool that standardizes project builds through conventions and dependencies. Maven aims to simplify builds through predefined directories and dependencies. It also provides dependency management, documentation generation, and release management. The document then discusses Jenkins, a tool for continuous integration that can trigger automated builds and tests. It notes Maven and Jenkins are often used together, with Maven for builds and Jenkins triggering builds.

1. By:
- Abdullah Ibrahim Salama
- Muhammad Abdul-Fattah Abulmajd

2. Agenda
 What’s a Build Tool
 Advantages of Build Automation
 What’s Maven
 Objectives
 Features
 Helps To Manage
 Why Maven Not Ant
 Gradle – A New Sheriff In Town
 Continuous Integration
 Why Continuous Integration
 Workflow
 Benefits
 What’s Jenkins
 Jenkins and Hudson
 Build Life Cycles, Phases, and Goals
 Plug-ins
 POM File
 What’s POM File
 POM File Example
 POM File Minimal Requirements
 Super POM File
 Further Readings
2

3. What’s a Build Tool
 Generating source code (if auto-generated code is used in
the project).
 Generating documentation from the source code.
 Compiling source code.
 Packaging compiled code into JAR files or ZIP files.
 Installing the packaged code on a server, in a repository or
somewhere else.
3

4. Advantages of Build Automation
 A necessary pre-condition for continuous integration (CI) and
continuous testing.
 Improve product quality.
 Accelerate the compile and link processing.
 Eliminate redundant tasks.
 Minimize "bad builds".
 Eliminate dependencies on key personnel.
 Minimize the risk of humans making errors while building the
software manually.
 Have history of builds and releases in order to investigate issues.
 Save time and money - because of the reasons listed above.
4

5. What’s Maven
 Maven is a powerful project management tool that is based
on POM (Project Object Model). It is used for projects build,
dependency and documentation.
 Maven was released in 2004. Its goal was to improve upon
some of the problems developers were facing when using Ant.
 Maven simplifies and standardizes the project build process.
 Maven increases reusability and takes care of most of the
build related tasks.
5

6. Objectives
 Maven’s primary goal is to allow a developer to comprehend
the complete state of a development effort in the shortest
period of time. In order to attain this goal there are several
areas of concern that Maven attempts to deal with:
 Making the build process easy
 While using Maven doesn’t eliminate the need to know about the
underlying mechanisms, Maven does provide a lot of shielding
from the details.
 Providing a uniform build system
 Maven allows a project to build using its project object model
(POM) and a set of plugins that are shared by all projects using
Maven, providing a uniform build system.
6

7. Objectives
 Providing quality project information and reporting
 Maven provides plenty of useful project information that is in
part taken from your POM and in part generated from your
project’s sources. For example, Maven can provide:
 log document,
 cross referenced sources,
 dependency list,
 unit test reports, and etc.
 Easy to migrate for new features of Maven
7

8. Objectives
 Providing guidelines for best practices development
 Maven aims to gather current principles for best practices development, and make it easy
to guide a project in that direction.
 For example, specification, execution, and reporting of unit tests are part of the normal
build cycle using Maven. Current unit testing best practices were used as guidelines:
 Keeping your test source code in a separate, but parallel source tree
 Using test case naming conventions to locate and execute tests
 Have test cases setup their environment and don’t rely on customizing the build for
test preparation.
 Maven also aims to assist in project workflow such as release management and
issue tracking.
 Maven also suggests some guidelines on how to layout your project’s directory
structure so that once you learn the layout you can easily navigate any other
project that uses Maven and the same defaults.
8

9. Features
 Simple project setup that follows
best practices.
 Consistent usage across all projects.
 Dependency management including
automatic updating.
 A large and growing repository of
libraries.
 Extensible, with the ability to easily
write plugins in Java or scripting
languages.
 Instant access to new features with
little or no extra configuration.
 Backward Compatibility
 Model-based builds − Maven is able
to build any number of projects into
predefined output types such as jar,
war, metadata.
 Coherent site of project information
 Using the same metadata as per the
build process, maven is able to
generate a website and a PDF
including complete documentation.
 Release management and
distribution publication
 Better Error and Integrity Reporting
9

10. Helps To Manage
 Builds
 Documentation
 Reporting
 Dependencies
 Including automatic updating
 SCMs
 Releases
 Distribution
10

11. Why Maven Not Ant
 Main difference is that in ANT you need to
define every thing i.e source dir, build dir,
target and etc. While Maven adopts
principle of Convention over Configuration.
 CoC results in
 Little/no configuration
 Following pre-scripted conventions
 Reasonable defaults
 Override when required
 Which means Maven has predefined project
structure i.e standard directory for source
files, test files and resources etc. 11

12. Why Maven Not Ant
 Maven introduced concept of repository, which is a central place to store all
libraries, JARs etc. Maven allows you to use central maven repository (remote) as
well as local repository and automatically download dependency during build
process.
 The local repository is a folder inside the machine in which a project is being
developed, acting as a cache with respect to the remote repositories.
 Apache provides a central repository containing thousands of common
dependencies, which is the default one.
 Maven does not rely on this specific repository, thus allowing users to define their
own custom repositories.
 While ANT based project generally use ${lib} as directory to store dependencies.
Manual dependency management.
 Changing and updating dependency is much easier in maven than ANT because you
don't need to manually download dependency. Having an organization wide central
repository also helps to remove redundancy across different projects.
12

13. Why Maven Not Ant
 Maven provides a uniform interface for building projects. You can build a
Maven project by using just a handful of commands. All you need to do is
download the project and run mvn install to build it.
 Also by knowing maven conventions and looking at pom.xml, one can easily
understand where source files are and what are project dependencies.
 ANT doesn't have any lifecycle, you need to define targets and there
dependencies. While Maven has lifecycle, which is invoked when you run
commands like mvn install. Maven executes a series of steps as a result of this
command to produce artifacts e.g. JAR file, which is end of life cycle
 Inheritance: This concept simply means that everything that is not specified in
a POM file is inherited from the upper-level POM.
 At the top level, Maven provides a parent POM defining all default
values.
13

14. Gradle – A New Sheriff In Town
 An open-source, build automation system, released in 2012, that
builds upon the concepts of Ant and Maven
 Has all advantages of Maven plus Ant flexibility.
 Google chose Gradle as the official build tool for Android
 Instead of XML, Gradle has its own DSL based on Groovy
 Apache Groovy is a powerful, optionally typed and dynamic language,
with static-typing and static compilation capabilities, for the Java
platform aimed at improving developer productivity.
 DSL: Domain-Specific Language.
 GPL: General-Purpose Language such as Java, C/CPP, and XML.
 Maven could have one advantage over Gradle which
is wide integration range with almost all IDE
14

15. Gradle – A New Sheriff In Town
15

16. Continuous Integration
 CI is a software development practice where members of a team
integrate their work frequently, usually each person integrates at
least daily – leading to multiple integrations per day. Each
integration is verified by an automated build (including test) to
detect integration errors as quickly as possible.
 This concept was meant to remove the problem of finding the late
occurrences of issues in the build lifecycle.
 Instead of the developers working in isolation and not integrating
enough, continuous integration was introduced to ensure that the
code changes and builds were never done in isolation.
16

17. 17

18. Why Continuous Integration
The continuous Integration process helps to answer the following questions
for the software development team:
 Do all the software components work together as they should?
 It’s always critical to ensure that all the software components work seamlessly
with each other.
 Is the code too complex for integration purposes?
 If CI keeps on failing, there could be a possibility that the code is just too
complex. And this could be a signal to apply proper design patterns to make
the code lesser complex and more maintainable.
 Does the code adhere to the established coding standards?
 By doing an automated test after the automated build, this is a good point to
check if the code meets all the desired coding standards.
18

19. Why Continuous Integration
 How much code is covered by automated tests?
 There is no point in testing code if the test cases don’t cover the
required functionality of the code.
 So it’s always a good practice to ensure that the test cases written
should cover all the key scenarios of the application.
 Were all the tests successful after the latest change?
 If a test fails, then there is no point in proceeding with the
deployment of the code, so this is a good point to check if the code
is ready to move to the deployment stage or not
19

20. Workflow
1. A developer commits the code to the version control repository. Meanwhile, the CI
server on the integration build machine polls source code repository for changes.
2. After a commit occurs, the CI server detects that changes have occurred in the version
control repository, so the Continuous Integration server retrieves the latest copy of the
code from the repository and then executes a build script, which integrates the
software.
3. The Continuous Integration server generates feedback by
e-mailing build results to the specified project members.
4. Unit tests are then carried out if the build of that project passes. If the tests are
successful, the code is ready to be deployed to either the staging or production server.
5. The Continuous Integration server continues to poll for changes in the version control
repository and the whole process repeats.
20

21. 21

22. Benefits
 Integration bugs are detected early and are easy to track down due to small
change sets.
 This saves both time and money over the lifespan of a project.
 Avoids last-minute chaos at release dates, when everyone tries to check in
their slightly incompatible versions.
 Constant availability of a "current" build for testing, demo, or release
purposes.
 When unit tests fail or a bug emerges, if developers need to revert the code-
base to a bug-free state without debugging, only a small number of changes
are lost.
 Because integration happens frequently.
 Increase visibility which enables greater communication
22

23. Benefits
 Spend less time debugging and more time adding features
 Proceed in the confidence you’re building on a solid foundation
 Reduce integration problems allowing you to deliver software more
rapidly
 Automate the build
 Make your build self-testing
 Automate deployment
 Continuous Integration is quality assurance
 Frequent code check-in pushes developers to create modular, less complex
code
23

24. What’s Jenkins
 Jenkins is a self-contained, open source automation server which
can be used to automate all sorts of tasks related to building,
testing, and delivering or deploying software.
 Jenkins can be installed through native system packages,
Docker, or even run standalone by any machine with a Java
Runtime Environment (JRE) installed.
 https://youtu.be/p7-U1_E_j3w
24

25. What’s Jenkins
 Jenkins offers a simple way to set up a continuous integration or
continuous delivery environment for almost any combination of
languages and source code repositories using pipelines, as well
as automating other routine development tasks. While Jenkins
doesn’t eliminate the need to create scripts for individual steps,
it does give you a faster and more robust way to integrate your
entire chain of build, test, and deployment tools than you can
easily build yourself.
25

26. Jenkins and Hudson
 Jenkins is a fork of Hudson, Hudson was original project which
was open source and supported by Sun. When Oracle bought
Sun, it took control over Hudson name and logistic platform of
Hudson, and provided Jenkins as the new platform.
 Essentially difference is that Maven is project management while
Jenkins or Hudson is a Continues Integration Frameworks.
 By using CI tools like Hudson or Jenkins you can trigger hourly or
daily builds automatically.
 Jenkins or Hudson can use Maven as build tool.
26

27. 27

28. Revisiting Maven
28

29. Build Life Cycles, Phases and Goals
 The build process in Maven is split up into build life cycles,
phases and goals.
 A build life cycle consists of a sequence of build phases, and each
build phase consists of a sequence of goals.
 A goal represents a specific task which contributes to the
building and managing of a project.
 When you run Maven you pass a command to Maven. This
command is the name of a build life cycle, phase or goal.
 If a life cycle is requested to be executed, all build phases in that
life cycle are executed.
29

30. Build Life Cycles, Phases and Goals
 There are three built-in build lifecycles: default, clean and site.
 Default lifecycle handles project deployment.
 Clean lifecycle handles project cleaning.
 Site lifecycle handles the creation of project's site documentation.
 The default lifecycle comprises of the following phases:
 Compile - compile the source code of the project
 Test - test the compiled source code using a suitable unit testing framework
 Package - take the compiled code and package it in its distributable format (i.e Java
ARchives – JARs)
 Install - install the package into the local repository, for use as a dependency in other
projects locally
 Deploy - done in the build environment, copies the final package to the remote repository
for sharing with other developers and projects
30

31. Plug-ins
 Maven follows a plug-in–based architecture, making it easy to
augment and customize its functionality.
 Build plugins are used to insert extra goals into a build phase.
If you need to perform a set of actions for your project which
are not covered by the standard Maven build phases and
goals, you can add a plugin to the POM file.
 Maven has some standard plugins you can use, and you can
also implement your own in Java if you need to. Thereby
enabling you to integrate tasks and workflows that are
specific to your organization.
31

32. Plug-ins
 These plug-ins encapsulate reusable build and task logic. Today,
there are hundreds of Maven plug-ins available that can be used to
carry out tasks ranging from code compilation to packaging to
project documentation generation.
 Types of plugins:
 Core plugins: plugins corresponding to default phases (i.e clean, and
compile)
 Packaging types/tools: plugins relate to packaging respective artifact
types
 Reporting plugins: plugins which generate reports
 Tools plugins: These are miscellaneous tools available through maven by
default
32

33. Graphical Illustration
33

34. What’s The POM File
 POM is an acronym for Project Object
Model.
 A POM file is an XML representation
of project resources like source code,
test code, dependencies (external
JARs used) etc.
 The POM contains references to all of
these resources.
 Build settings also can be defined in
the POM file i.e which version of java
to use, or the final build name of
artifact generated etc.
 The POM file should be located in the
root directory of the project it
belongs to. 34

35. POM File Example
<project>
<modelVersion>4.0.0</modelVersion> <!--always 4.0.0 for Maven 2.x POMs-->
<--a group of values which uniquely identify this project -->
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId> <!-- project name -->
<version>1.0</version> <!-- project version -->
<dependencies> <!-- library dependencies -->
<dependency> <!-- this project will use junit for testing -->
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope> <!-- Scope of this Dependency is testing only -->
</dependency> <!-- closing junit dependency tag -->
</dependencies> <!--- closing all dependencies tag -->
</project>
35

36. POM File
 Minimal requirements for a POM
 Project root
 Model version
 Group id
 Artifact id
 Version
36

37. POM File
 The project tag: this is project root tag. You can specify the basic
schema settings such as apache schema and w3.org.
 The modelVersion tag: sets what version of the POM model you are
using. Use the one matching the Maven version you are using. Version
4.0.0 matches Maven version 2 and 3.
 The groupId tag: This is an Id of project's group. This is generally
unique amongst an organization or a project, the project will be
located in the Maven repository under a directory structure matching
the groupId.
 For example, a banking group com.company.bank has all bank related
projects.
37

38. POM File
 The artifactId tag: contains the name of the project you are building
 For example, consumer-banking.
 Along with the groupId, the artifactId defines the artifact's location within
the repository
 The version tag: sets the version of the project. Along with the groupId, It
is used within an artifact's repository to separate versions from each other.
 Example:
 com.company.bank:consumer-banking:1.0
 com.company.bank:consumer-banking:1.1
38

39. Super POM File
 The Super POM is Maven’s default POM. All POMs inherit from
a parent or default (despite explicitly defined or not). This
base POM is known as the Super POM, and contains values
inherited by default.
 An easy way to look at the default configurations of the super
POM is by running the following command:
 mvn help:effective-pom.
39

40. Further Readings
 Books:
 Maven Essential, by Prabath Siriwardena
 Introducing Maven, by Sudha Belida and Balaji Varanasi
 Continuous Delivery with Docker and Jenkins, by Rafał Leszko
 Continuous Integration: Improving Software Quality and Reducing Risk, by Andrew Glover, Paul M. Duvall,
and Steve Matyas
 Online Tutorials:
 https://maven.apache.org/index.html
 http://javarevisited.blogspot.com.eg/2015/01/difference-between-maven-ant-jenkins-and-hudson.html
 http://tutorials.jenkov.com/maven/maven-tutorial.html
 https://www.tutorialspoint.com/maven/index.htm
 https://www.tutorialspoint.com/jenkins/index.htm
 https://www.tutorialspoint.com/continuous_integration/index.htm
 https://www.youtube.com/playlist?list=PLhW3qG5bs-L_ZCOA4zNPSoGbnVQ-rp_dG
40

41. 41

42. 42

43. 43

44. 44