Maven and Jenkins: Building, Deploying, and Testing a Java Application

14.1 The Session Plan

14.1.1 What We Build Today

How does a piece of Java code written on a laptop become an application that runs on a server? This session answers that question by walking one complete CI/CD loop with two tools: Maven and Jenkins.

We create a very basic Java project, build it with Maven, deploy it with Jenkins, and test it with JUnit. That sequence — code, build, deploy, test — is the whole day's agenda, and it mirrors how real DevOps pipelines work.

Both Linux and Windows are fine for the basic deployment architecture we use. Git covers the code repository side, and Jenkins handles most of the CI/CD operations. Maven is the building piece: building an application can mean dependency building. If you have 10 or 20 projects together, or multiple files, and you want a lot of dependencies added, you need Maven for that. Nearly everything else stays similar to what was covered before.

14.1.2 Testing Tools Beyond JUnit

Testing today uses JUnit because the project is Java. But a DevOps engineer should know the wider testing landscape, and it splits into categories:

• Unit and hybrid testing: Karma and Jasmine are mainly for website testing and hybrid testing. Cucumber serves the same hybrid space, and it can also be used for mobile applications that rely on a hybrid architecture. Mockito was named for mock testing — this is the standard Java mocking framework, used to create fake versions of objects so a unit test can isolate one class from its collaborators. Selenium is mainly for automation testing — the suite of tools that drives a real web browser through your application and checks that pages behave the way users expect.

Real-world: these tools exist because every project type needs its own test strategy. A pure Android native app, a web app, and a hybrid mobile app all get tested differently.

14.1.3 Quality Tools: Linting

For quality measurement, we use lints. A lint (from the old Unix program lint that flagged suspicious code) is a tool that reads your source code and reports problems — style mistakes, unused variables, dangerous patterns — without running the program. JavaScript has JavaScript Lint and JSLint, Java has Java Lint, and Android and iOS each have their own lints. ESLint is the commonly used one for JavaScript, but every platform has its own lint tool.

14.1.4 Load, Security, and Monitoring Tools

LoadRunner and JMeter are used mainly for security testing and other purposes such as load and performance checks — JMeter, for example, lets you simulate hundreds of users hitting a server at once and see whether it stays responsive. Then there are analytics and monitoring tools that provide more insights; these are not covered in this session, but at least you should know they exist and what they do as a DevOps engineer. These are the basic things you need for a DevOps CI/CD process.

14.1.5 Cron Jobs and Architecture Topics

Two more items sit on the agenda. Cron jobs schedule all our scripts and jobs — we use them in shell scripting and inside Jenkins. And solution architecture with network topology is part of your network architecture and deployment architecture knowledge; it is the environment your pipeline deploys into.

14.2 Java Architecture: What Maven Actually Builds

14.2.1 From Java Source to Class File

Since the project today is Java, we look at the Java architecture so you understand the process. You don't need to know every detail, but you do need the process, because the POM file you create for your Maven application is built around it.

Every Java file, when it compiles, becomes a class file. A class is a kind of executable — it is not fully executable on its own, but via the Java interpreter we can execute it.

14.2.2 The Parts Inside a Class File

The class has multiple parts:

• Method area — where all your functions are present.
• Heap memory — a kind of runtime memory where objects live while the program runs.
• Stack memory — used for our operations, typically local variables and method calls.
• Native stack — mainly for embedded applications. If it is an Android application, up to this point it is the Java layer, and below it comes the Android layer.
• Library for GC — the garbage collector, for clearing up memory that is no longer used.
• Just-in-time compiler — see below.

14.2.3 The Just-in-Time Compiler

Java does not compile everything beforehand. This is mainly Spring Boot architecture, or Spring architecture: when the application is about to run, it compiles and starts running at that moment. Because the JIT compiler does the work at the point of execution, the efficiency is better for this approach. This is why a Java app can feel slow to start but fast afterward.

14.2.4 The Java Build Pipeline

The full process of a Java application: you have Java code, the Java compiler compiles it into a class file that holds bytecode, then it gets converted into a jar or a war based on whatever packaging we do, and finally we run it in the operating system of our system — Windows, Linux, Mac, whatever it is.

This is exactly what we do today as part of our Maven build. All the steps: the Java file is already there, we compile that into a class, then to a jar, then we run the test files, then we run it and test everything.

14.3 The Common Deployment Architecture

14.3.1 From IDE to Code Repository

Here is how applications normally get deployed. You write code in an IDE — the integrated development environment, the editor with built-in tools for writing, running, and debugging code. Tools like Eclipse, IntelliJ IDEA, Android Studio, and Xcode are all IDEs; the demo in this session uses Visual Studio Code for the source files. Once the code is written, you put it in a code repository, and for that we use Git and everything around it.

14.3.2 Two Deployment Paths

Once the code is in the repository, there are multiple ways to implement it:

1. Direct deployment — deploy straight into a web server. For web applications we normally do that.
2. Build operation — package the code into multiple executables and push them to a marketplace.

14.3.3 Packaging Formats on Every Platform

The packaging formats depend on the platform: Android APK, iOS IPA, web WAR file, Java JAR file. EXE fits a Windows application, DMG for Mac, PKG for Linux — whatever you are doing. Once packaged, you push it to whichever marketplace you have: the App Store or your own website, where it lands in the application layer.

Real-world: this is why the same source code can end up as an APK on Google Play, an IPA on the App Store, and a WAR in a company's internal web server — one codebase, many packages.

14.3.4 The Layers of a Deployment

The deployment has distinct layers. There is the web layer, the application layer, and then the runtime, which could be in the cloud, along with all the databases and everything. This is the overall deployment architecture of DevOps.

Within it, the Git layer is the actual code layer, holding the services that run in the integration and DevOps layer. Everything is documented in detail, but nothing here is complex — you just need to know what is present in each layer.

14.4 Maven: The Build Tool That Changed the Game

14.4.1 Life Before Build Tools

Maven is a build tool, mainly for building. Before Ant, Maven, and the rest — and there are multiple build platforms: Ant, Maven, Gradle, Groovy — building was manual. With old Java, C, or C++, you compiled 10 to 20 files in one shot with a single command: GCC for C and C++, javac for Java. You had to list every file in one compilation command. Then, for a jar, you ran the jar command separately. Everything was manual, or you fell back on shell scripts. That was the olden-day concept.

14.4.2 Ant, and the Shrinking of Steps

Then these tools started coming in, and they reduced the issues. When Ant arrived, it was a kind of boon for developers. Maven is built over Ant — it is a smooth way of doing the Ant process. Ant had some crude things: where GCC and javac needed 10 steps, Ant needed 5, and Maven needs only 3. The tools kept shrinking the complexity of the build, the compilation, and everything else we do. They simplified each and every part of the process.

The pattern across the industry is the same: each generation of build tools removes steps the developer had to remember, until the build is one command repeated everywhere.

14.4.3 What Maven Gives You

Maven's value comes in four pieces:

1. It makes the build process easy. That was the first thing — simplifying compilation and packaging.
2. A uniform build system. Flutter uses a single application for all embedded systems; Maven is similar. One common build works across Windows, Mac, Linux, the cloud, and DevOps platforms — you do not implement different things for different layers.
3. Quality. Maven supports everything: testing, linting operations, performance, and lots more. Only the deployment part needs Jenkins; even Jenkins integration can be done inside Maven. The POM file can grow exponentially, with all operations done in a single file. That is why it gives good quality.
4. Better development practices. When you compile, Maven itself provides a lot of warnings on top of your compiler: this is not correct, that is not correct, try to clear this, make the file size smaller, break into multiple files, reduce the method size, reduce the number of lines, reduce the number of characters. It goes to that level, and for developers it is a boon — you can filter out a lot of issues before they ever reach production.

Exam note: today's quiz covers only Maven and Jenkins, so the "why Maven exists" story and the POM details below are the core study targets.

14.4.4 The POM: Project Object Model

The POM — Project Object Model — is a manifest file. Every framework has a manifest; Maven's is the POM file. It declares each and everything about the project, and it is the heart of the application. To read one, you can go from bottom to top; that makes it easier to understand.

14.5 Anatomy of a POM File

14.5.1 The Core Coordinates

The example POM is the minimal one given by the Apache Maven project itself. One important thing: the 4.0.0 model version should not be changed at all. This is the POM version everybody uses, and it is not going to change — it is frozen now. They are not going to upgrade it and we cannot even downgrade it. It stays static at 4.0.0.

Then come three things, like the package name, package ID, and version you put on any Java project:

• groupId — the company ID of whoever is doing the project. It could be a company or your own thing; normally we put com.something.something style.
• artifactId — the project name. Whatever project you are doing, whatever its purpose, that is the artifact ID.
• version — the version number. It could be a patch version, an upgrade version, or a new fully updated version. It has a three-digit structure, covered in the versioning section below.

A minimal POM, exactly like the Apache starter example, looks like this:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>
  </project>

14.5.2 Packaging: Jar, War, EAR

The packaging part says whether we produce a jar file, a war file, or an EAR file — whichever executable we are going to create. This one declaration controls what kind of package the build makes. If you do not state it, jar is the default.

14.5.3 Dependencies, Parent, and Modules

• Dependencies: in a small project you may have none, but if you use third-party plugins you add them here. You cannot implement everything yourself. For example, a date framework not provided straightforwardly by Java, UI widgets and components — whatever you need, you add via the dependency tag.
• Parent and child: used for inheritance. There is a parent and a child; the child can inherit a lot of things from the parent, and the parent can also take something from the child. That is how inheritance happens, and that is why the parent tag exists. In a real company you typically have one parent POM that pins the versions of every library, and every project child inherits those versions instead of repeating them.
• Dependency management: this manages local dependencies and runtime dependencies — like a Docker container holding runtime dependencies. Compilation-time things go in one bucket, runtime things in another; when the pod is running, it reads the information it needs from here.
• Modules: similar to dependencies, but this is your own local code. A dependency is a third-party thing you import as a plugin; a module is a local project you already have, linked by file path when creating the jar.

14.5.4 Properties and Build Settings

Properties specify which version of JDK or which tool version the build should use — for example, which Java compiler version. You state whatever you are trying to do here.

Build settings control which build number, how big or how low it should be, and which version range to support. If you have used Android or the App Store, you have seen "this application doesn't support this phone." That is the build in action: the minimum version for building and all these constraints.

14.5.5 Project Metadata: Developers vs Contributors

Project-specific fields include the name of the project, its description, the URL of your application, when it got created, what license it uses, which organization it belongs to, and who the developers are.

The difference between developer and contributor: the developer is the one who created the project. The contributor is the one who helps — someone comes and says "there is a bug, can we fix it?" and if you say yes, they fix it, contribute, and come and go. That is what the contributor field is for.

14.5.6 Environment, Distribution Management, and Profiles

Environment settings are internal: for Jenkins integration, sending mails, integrating Git, integrating other repositories that need to be built before ours runs, and plugins — code that can be directly compiled and used as a plugin.

Distribution management says where the artifact should go: the web store or your website — where it should be pushed.

Profiles are a role kind of thing: who can actually run all these operations. Some parts belong mainly to the development team, others to the builds and integrations team.

This is a full-fledged POM. There can be bigger POMs with other things, but this much covers real-time operations. There is also a "fat POM" with every tag available in Maven; you can look it up in the reference repository when a specific scenario needs something extra.

14.5.7 Scopes: Compile, Provided, Runtime, Test, System

Scope is not part of the POM body — you add it as part of your Maven command or dependency declaration. Scope says whether you are going to package, install, compile, or run:

• compile — default. It compiles here itself. If you say nothing, Maven picks the latest or some default version. The dependency is needed both to build the project and to run it.
• provided — similar to compile, but you state what version of JDK or what is needed; you provide your own things. The code compiles against it, but the runtime environment supplies it — for example the servlet API on a web server that already ships it.
• runtime — the code is not available with you. Once you deploy, you get the code there and run it then. Runtime waits for compilation until you deploy. The build does not need it to compile, only to run.
• test — only for the testing part. It never runs in production deployment; internally it runs for you. JUnit is the classic example: needed for the test phase, never shipped.
• system — for local things. You say "this is available here, get it from the local directory." If you put system and do not give the exact file path, it throws an error. The system path needs a hard-coded path to be provided.

14.5.8 Optional Dependencies

Optional is an important flag. Suppose two different packages or repositories: one has some information, another has some other dependency. For example, a date library — in some scenarios you do not even need it; without it your project still runs. Then you can mark that dependency optional: even if that date repository fails to compile, your application still runs. If you do not mark it optional and it fails, you cannot build at all — that becomes a problem. There is a common pattern: a third repository only needs the first repository; the second repository is optional to it, so the third never needs to care about it — it just calls the first.

14.5.9 Student Questions: What Can Maven Package?

14.6 Semantic Versioning

14.6.1 Major, Minor, and Patch

Versioning has its own semantics: the major version, the minor version, and the patch. You must be very, very clear when giving versions — whether you are putting a small patch, a minor enhancement, or a major change — and give the numbers based on that.

A version number has three slots, written as major.minor.patch:

• Major (the leftmost number) — changes when the change is big enough that old users may need to adapt: new features with breaking changes, new architecture.
• Minor (the middle number) — changes for a small enhancement that adds something new without breaking anything that already works.
• Patch (the rightmost number) — changes for an immediate fix: a bug in production patched right away.

The three rules, each with a worked bump:

• A major change moves 1.0.0 to 2.0.0:

$$\mathrm{1.0.0}\to \mathrm{2.0.0}$$

• A small enhancement moves 1.0.0 to 1.1.0:

$$\mathrm{1.0.0}\to \mathrm{1.1.0}$$

• An immediate patch — a bug in production fixed right away — moves 1.0.0 to 1.0.1:

$$\mathrm{1.0.0}\to \mathrm{1.0.1}$$

In the demo POM the version is 0.1.0: when asked "what is one?", the answer is the minor version — only small changes are planned, so the minor slot is incremented.

14.6.2 Why Versioning Discipline Matters

This matters because as a DevOps engineer you need to know all these things properly to actually release. If the versioning is wrong, it becomes a problem for you and for your customers: people will think it is a major version, they will download it, and they will say only a small thing is present. That kind of disappointment is exactly what semantic versioning prevents.

14.7 Maven Commands and Plugins

14.7.1 The Core Commands

The major commands we normally use:

• mvn compile — compiling.
• mvn test — testing.
• mvn package — the executable gets created, a jar or war.
• mvn install — does all these things in one shot: compiles, creates the package, tests it, and then copies the created jar or war to the local dependency directory, normally the hidden .M2 directory. This is where the confusion between compile and install comes from.
• mvn clean — removes the target directory (the class files and jar). The same job can be done with rm -rf on Linux or del /f on Windows.

14.7.2 Running and Checking Versions

To execute your application: java -jar <name>.jar. To check the Maven version: mvn --version or mvn -v. Only those two spellings work — a plain mvn version (no hyphen) does not work; Maven just tries to build and throws an error. The version output shows useful build information: the Maven version, the Maven home, the Java version, the encoding, the locale, the operating system, and the architecture it is building for.

14.7.3 The Surefire Plugin

Two plugins matter. Surefire is the unit-testing tool mainly used by Maven itself. You create a JUnit test case and this plugin executes it; you barely touch it yourself. Surefire also generates the test report — how many tests ran, what did not run, what failed.

14.7.4 The Shade Plugin and Fat Jars

The shade plugin — shade means shaded — is the one you actually touch. It packages the class files into a jar, and its purpose is best seen with the classical example: you have a hello world program, one class, and you implement a date functionality, another class — two things that both get added into a single jar. If you break that jar open, there will be two different jars with all dependencies properly added. Now another jar tries to use your jar: it uses Java 1.8 while you use Java 11. Two different versions, a dependency problem. Shade corrects all your dependencies and renames your versions to be compatible with other things. Once you give out your shaded jar, you can be happy — you do not need to worry about compatibility issues. The shade jar takes care of it.

That is why the result is called a fat jar: each and every application creates its own jar, everything has its own version, and nothing conflicts with anyone else's. The demo uses the shade plugin at version 3.2.4 — the latest at the time — bound to the package phase, with the goal shade that creates the shaded jar, and a transformer configuration that says which class is the entry point.

14.7.5 Student Questions: Compile vs Install

14.8 Cron Jobs: Scheduling Scripts and Builds

14.8.1 The Five Fields

A cron job is mainly for scheduling, and it is a very, very simple file with just five parameters:

$$mhdmow$$

• $m$ — minute, from 0 to 59. The 60th minute becomes the next hour.
• $h$ — hour, 24-hour clock. If I want 2:35, then 35 goes in the minute field and 2 PM means 14, so 14 goes in the hour field.
• $d$ — day of month, 1 to 31. January 15th is 15.
• $mo$ — month, 1 to 12, where 1 means January. The pair "1 and 15" means January 15th.
• $w$ — day of week: Sunday, Monday, and so on. If you remove the day and month, you can put the week part directly — every Sunday it should run, or every Monday.

14.8.2 Example Schedules

Two concrete schedules from the walkthrough:

2:35 PM every day:

$$3514\ast \ast \ast$$

Every minute (used for the Jenkins demo build so the timing is visible):

$$\ast \ast \ast \ast \ast$$

The slides carry more examples: running at 12 PM noon every day, at 10:15 AM every day — all the different ways of running via cron. It is very, very simple: just five parameters, and you can play with all the numbers and test it yourself.

14.8.3 Wildcards and Non-Standard Extensions

There are some wildcards, but this part is not standard: sometimes they work, sometimes they do not. The standard expressions are the safe path; you can create everything manually. Some systems offer "at monthly" — automatically once every month — and "at hourly" — every hour once. These extensions exist on some operating systems and not on others, so always follow the standard. Today we also see cron used inside Jenkins.

14.9 Building Hello World: The Worked Demo

14.9.1 The Source Files and the POM

The demo starts with a very, very basic Java file: a hello world class and a greeter class. The main method calls the greet function. Two files total: one is the hello world entry point, one is the greeter. The task: build this Java file into a class file, convert it into a jar, execute it, test it, and install it.

For that we need a pom.xml — the manifest that declares everything. The demo POM keeps 4.0.0 untouched. The groupId is spring (an example project, so it was just left as-is), the artifactId is the project name gs-maven, and the packaging is jar. The version is 0.1.0 — the minor version, because no big changes are planned.

The properties section sets the Java compiler to 1.8. One property is mainly for the executable: the version number and company in the file name. The resulting executable will be named gs-maven-0.1.0.jar. The compiler property controls which version compiles your files.

The next part is the maven-shade-plugin 3.2.4, for generating the jar. The execution is bound to the package phase — the point where the build becomes a jar or war file. If no executable type is given, it defaults to jar; war must be specified explicitly. The goal is shade. The configuration names the package and main class: in the hello package there is a hello world Java application that needs converting into a jar — which jar, the shaded jar — and it has a Java 1.8 dependency. That is what we explain to Maven in the POM file.

Real-world: the same POM pattern — groupId, artifactId, version, packaging, compiler properties, and the shade plugin — appears in thousands of Java and Spring Boot projects in industry.

14.9.2 Step 1: Compile

First check the version: mvn --version prints Maven 3.8.6, the Maven home path, the Java version, encoding UTF-8, English India locale, Mac OS, and the architecture. mvn -v is the same thing. Running plain mvn version throws an error because it tries to build instead.

Then mvn compile: Maven scans for the project and finds it — the output echoes the organization ID, artifact ID, version, and the jar packaging we gave. With no resource directory it says "skipping". Because the code was already compiled once, it says "nothing to compile — all classes are up to date". So the demo deletes the target directory — the executable location — and compiles again. This time it actually compiles: "Compiling 2 sources". The two Java files are taken from the src folder and turned into class files under target/classes. Opening them shows special characters — a class file cannot be read as text; it is bytecode. The build also lists which classes got created and which input files were used.

14.9.3 Step 2: Package

mvn package runs the same checks — compilation is up to date, no resources — then testing starts: Surefire tries to run a test case, but since there is no test case it says "no tests to run". Then the jar plugin builds the jar: the format comes from the artifact ID gs-maven, the version number, and the packaging, producing gs-maven-0.1.0.jar. After the original jar is created, the shade plugin runs and creates the shaded jar. The shaded jar replaces the original and gets renamed to the exact file name we gave. The result: a normal jar and a shaded jar both created, with the final name on the fat jar.

14.9.4 Step 3: Run

Execute with java -jar on the file in target: the output shows "hello world". The independent jar also exists — both get the same output. Since there is no test case, testing reports "no tests to run". The run part is complete.

14.9.5 Step 4: Install

mvn install is the interesting one — the fat jar versus normal jar concept. Without the shade part, you take your jar and put it in a directory where all your dependencies are present; that is what install does. The output shows the local path under the user's home — it is not putting the jar into a local folder of ours, it is going into the repository part: .M2/repository, where all the dependencies are already available. If we deploy a website, we deploy that entire path — the jar file along with the dependencies. With the shade part, that whole path is not needed; the single shaded jar can go directly. Shade is not third-party — it is Maven's own plugin — but if you are not using it, install is the path to follow.

14.9.6 The One-Shot Shell Script

Everything seen as separate commands is collected into maven.sh, with one more step: clean first. So the script cleans, compiles, packages, runs, tests, and installs — the full sequence in a single file. Running it shows the whole lifecycle: cleaning complete, compiling, class files ready, resources and jar built, the executable runs and prints "hello world", the shaded jar is created, tests skip because none exist, and the install step happens at the end.

This is the form mostly used for Jenkins scripting and deployments: either a shell file, or each and every command typed separately and waited on. Shell scripts are easier to manage and maintain, and they fail the entire build if one step fails.

14.10 Adding Dependencies: Joda-Time and JUnit

14.10.1 The Updated POM

The next step keeps the same greet function but adds two more lines: getting the local time and printing the local time, using a plugin — org.joda.time.LocalTime — which is a third-party vendor for us. Now we have a dependency, and the POM changes slightly: everything stays the same (4.0.0, file name, JDK 1.8), but a dependencies block appears with two entries:

• Joda-Time — groupId org.joda.time, artifactId joda-time, and the vendor's version number. These three are not ours; we take them from the vendor who provides the library. The demo did not quote the version number; Joda-Time's own releases live on the 2.x line (a stable release around this Maven version is 2.10.x), and you copy the coordinates — group, artifact, and version — exactly as the vendor publishes them.
• JUnit — groupId junit, artifactId junit, version 4.12, with scope test. Without a scope, the default is compile — used for compiling and building. With scope test, Maven understands this works for the testing part only, and Surefire uses the JUnit test case to build and run the tests.

Most real POM files look like this one: more dependencies, sometimes more properties, different source and target — but the basic structure is the same block.

14.10.2 The Test Case

The test is a very, very small one: it checks whether the hello string is present in the greeter method. Whenever the greeter is called, hello is there, so the test reports success. Nothing beyond that.

14.10.3 Building and Testing with Dependencies

The demo removes the target directory (mvn clean or rm -rf/del /f) and runs mvn compile — two files compiled, the class folders look the same as before. The difference appears at the jar stage. mvn package runs the test: "Test case run one. Failure zero. Error zero. Skip zero" — which means it passed. If any of those counts were one, something had a problem; here it ran properly with no issue. Surefire completes the test, the jar file is ready. Then java -jar with the gs-maven jar in target prints the local time and hello world — the Joda package got bundled inside the jar, which is why the time appears. The install step runs last and is examined in detail in the next section.

14.10.4 Student Questions: Source, Target, and the Docker Idea

14.10.5 Why Maven Is Mostly a Java Tool

14.11 Inside the Jar: Fat Jar vs Thin Jar

14.11.1 A Jar Is a Zip

A jar file is a kind of zip file. Everything is a zip file in the end: EXE, DMG, PKG, IPA, WAR, JAR, EAR. You can open any of them with an unzipping tool and look inside — which is exactly what the demo does to contrast the two jars.

14.11.2 Inside the Original Jar

Extracting the original jar shows two folders: the hello folder with greeter.class and helloworld.class — the basic classes — and the meta-information, META-INF, used mainly by Maven. Inside it, the manifest file holds: the manifest version, the created-by field, the JDK version used, and the main class — hello.helloworld. The main class is the important information: Maven reads it and executes hello.helloworld directly, and since that class depends on greeter, greeter runs automatically.

The Maven directory inside the jar contains two files: the company name we gave as the organization ID, then the artifact ID, and inside that, two things: pom.xml — the exact XML we created — and a property file with artifact, group, and version, the same values we gave in the POM. Because everything is present, the jar can run independently; if something more is needed, it can be downloaded via this pom file.

14.11.3 Inside the Shaded Fat Jar

The complete jar looks different from the start: a new directory appears — the org directory for Joda. The hello classes are there, META-INF has the manifest and a license (present because third-party plugins are used), and Joda's packages are inside. For Joda there is its own Maven directory: a property file (artifact, group, version) and a pom, and inside that pom all of Joda's own dependencies — everything it needs. The contributors and every detail came from the Joda repository. Other classes Joda uses are present too — chrono, convert — everything. The jar also holds the test artifacts: the test class, the surefire report showing what ran, what did not run, and any failures — created by Surefire itself, internally.

That is the speciality of the shaded fat jar: whatever dependency Joda has, its dependency, its dependency's dependency — all available here, so the jar runs independently without any problem. You can deploy it and keep quiet; everything is taken care of within the jar file itself. If you have multiple dependencies, multiple folders appear here and the jar grows exponentially. The original jar is smaller and needs the shared dependencies; the fat jar is bigger and needs nothing else.

14.11.4 Install, the .M2 Repository, and Thin Jars

Now the install destination: inside the internal user home there is a .M2 folder — Maven's own repository. The repository holds other repositories used by Maven, and our own package sits under an "org" path. Joda-Time and JUnit are all there, already downloaded. Because all these packages are present, we can keep our jar small — a thin jar, not a fat one. Install creates a very, very light jar and puts it in the dependency section where all dependencies already live. The dependencies were downloaded by Maven previously; the fat jar would take all of those folders and convert them into a single jar file, while the thin jar keeps them in the shared path.

14.11.5 Student Questions: What mvn clean Does NOT Delete

14.12 Jenkins: Setup, Dashboard, and Console Output

14.12.1 Jenkins Is a Java Application

Jenkins is again a jar file — a Java application. The setup uses a shell script that calls Jenkins, telling it to listen on localhost: 127.0.0.1, the loopback address, which is what localhost is. The port given is 5050, so Jenkins runs on port 5050. This is a local Jenkins, not a server. Two extra things are in the script: the port and a localhost flag. Normally you do not even need port 5050 — the default Jenkins port is 8080, but another program was already running there, so a different port was needed. The local Git repository needs an extra flag because newer Jenkins versions do not allow the use of a local Git repository; it was added to fix a Git issue. Normally you just call Jenkins.

If you double-click the executable you can see it run, and internally it is running from a war file. Jenkins shows "Jenkins.war" when it starts. So the war file is the internal packaging, but the command used to run it is the jar command — Jenkins is executed as a jar.

14.12.2 Student Questions: Jar or War?

14.12.3 The Dashboard and Build Statuses

The dashboard shows the projects: a Flutter project that is failing, a Kubernetes project not built, and the Maven project, which is successful. The status symbols are weather based: if it is raining, the build has some problems or errors; not started has its own symbol; sunshine means successful.

Opening the Maven project shows all the statuses: last build, last failed build, successful build, failed build, unsuccessful, completed. A failed build means it failed; unsuccessful means the build was terminated abruptly. "Success stable" means everything is success — there can be some in-between failures, but the build still got success; stable means every run is success. Completed means that build got completed fully. The last build updates every now and then based on whatever process is running.

The timing list shows the cron job in action: builds at 55, 54, 53, 51, 48, 47, 46 — the big gap happened when the service stopped for two or three minutes. Apart from that, every 1 minute it ran. The cron job was set to run every minute. The workspace shows source, target, and test folders — everything from the Maven build is there.

14.12.4 Console Output and a Failed Build

The "Build now" button builds immediately: the last build was 199, clicking it starts build 200. Inside the build, the console output shows each and everything: who ran it, what command was executed, where it executed, and the status. The build runs mvn clean — deleting — then compiling, then packaging, then testing, then installing, and after install it executes the application, which is why the run comes last. The same shell script shown earlier is what actually runs, and every step happens every time.

A failed build is instructive too: opening the last failed build shows "Build failure" with the reason — the goal you specified requires a project to execute, but there is no POM. Please verify. The console spells out what the problem was and what caused it, giving the entire output so you can find the cause. The same output can be viewed as plain text. These are the basic operations in a Jenkins setup.

14.13 Configuring a Jenkins Project

14.13.1 General Settings and Source Control

Jenkins provides a lot of configuration. The project has a description — the demo project uses "Demo project explains CI/CD" to say what the project is about before starting a new build. Each option has a help text you can click when you do not understand what it means; the help gives a full-fledged understanding of each setting.

Then: is it a GitHub project or not? If it is, you give the github.com URL and the name. If you have any parameters — remember compile-time and runtime scopes: a runtime build needs parameters, like the -D flags seen in the Jenkins start command — you configure them here, choosing what kind of parameter it is.

If it is a Git project, you give the repository name and credentials. If you have none, you add them; you give the password and everything, and Jenkins GitHub integration happens — Jenkins integrates to your Git, and both run together. That is the Git, Maven, and Jenkins integration.

Throttle builds lets you slow or speed builds. Concurrent builds: normally we do not enable it. If a build comes while one is running, it waits — the new build is queued, and the running one shows "waiting for the other build to complete". Executing multiple builds at once risks resource problems: some code gets compiled, some does not, all that confusion comes. There are more advanced options: how many times it should retry on failure, when it should wait — like at 12 o'clock you keep quiet for half an hour — block the build if another project is running or if somebody is downloading, or use a custom workspace.

14.13.2 Build Triggers: The Five Ways

There are five types of triggers:

1. Trigger builds remotely (server execution). You have a Jenkins client on your local system; you trigger a build to your remote system. We do this mainly for security: if somebody tries to run a shell script directly on the server, it throws an error saying "I am not enabled for running shell scripts." But from your local repository you can trigger a shell script, run a shell here, and execute it on the server. That is server execution.
2. Build after other projects are built. You have a back-end project and a front-end project. The back end should run properly and get success before the front end runs, because the front end depends on the back end: without the API logic, testers testing the front end first would crash — the back-end API is not there. So you enable "build after other projects", give the project path, and choose the condition: trigger only if the build is stable (the normal choice) — even if it is unstable, you would still build (very, very rare), or even on failure you would not build. Normally we go only with the stable condition.
3. Build periodically (cron). The demo runs every minute; you can change it to every hour. Jenkins shows the schedule: last run at 8:18, next run at 9:18, Indian Standard Time.
4. GitHub hook trigger. When code comes into GitHub, GitHub intimates Jenkins: "Jenkins, I got some update — can you build it?" Then Jenkins automatically starts building.
5. Poll SCM. This is the reverse: Jenkins goes and verifies GitHub. You schedule it, for example every five minutes — it checks every five minutes once, and if a new change has come, it runs.

The recommended, efficient way is the GitHub hook (or polling): build only when a new change arrives. The periodic trigger wastes resources by building on a timer — the demo kept it only for testing, to show all the mechanics.

14.13.3 Build Environment Options

The build environment options are mainly for security and failure strategy:

• Delete the entire workspace before build — do not use this at all. Your code gets totally destroyed and you will not even get it back. If you add it by mistake, it becomes a bigger problem — the entire codebase is gone.
• Secret text — for encryption and decryption of secrets.
• Timestamps — if you want them on the console output.
• Build lock — lock builds and ask what kind of termination: absolute means after a fixed deadline, for example five minutes, end it; elastic takes the average of everything — if a build normally succeeds in two minutes and this one takes more than three or four, it knows it is likely stuck; no activity means if nothing is happening, end it.

14.13.4 Build Steps

There are multiple ways to execute a single task. The demo used a shell script — shell scripts are mainly for Linux, Unix, and Mac. Other ways: batch files (.bat) for Windows applications, Ant scripts, Gradle, and Maven targets.

Why not Maven targets here? Because each Maven target needs its own build step: mvn compile, then mvn install, then mvn test — multiple lines, multiple build steps. The shell script does the same thing in one step, and if something fails, it fails the entire build. It is the easiest, shortest, most optimized way for this scenario — your scenario could differ, and with multiple things you would use Maven-level targets, giving the Maven version, the goal (scope or package), and the POM file.

This is the main reason the POM file lives in a different place and the build runs in a different place: the Jenkins server is in a less secure area — it is just a deployment server without the code — and anyone there could read your POM file and see what you are deploying. So the code stays in one place, the build happens in another, and only the shell file goes to Jenkins — nobody can read what is there. You can also add multiple build steps, one after another: first you complete this, then that, then that.

14.13.5 Post-Build Actions

Once the build is complete, post operations run: send a mail, publish the JUnit results, archive an executable, build the next project, download the result, release release notes — a lot of things, and everything can be automated. If you enable email, you give the recipients and everything. The Git publisher says where to publish, only on build success, which branch — all configurable. It reduces your load: you enable once, set all the configuration, sit quietly, and enjoy the life — it does everything for you. When the configuration is complete, apply it and save it.

14.14 Managing Jenkins

14.14.1 The Plugin Manager

How did Jenkins get its Maven dependency, Gradle dependency, and email dependency? Jenkins does not have all dependencies built in — that is the Manage Jenkins part, with the plugin manager. Opening the plugin manager shows installed plugins: Ant, Apache, and more. The available tab shows everything: Git server, Pipelines, JavaDoc, Docker, Kubernetes — whatever tool you want, whatever Jenkins supports, it is present. You download and install it, and then it becomes available in your configuration.

14.14.2 Global Tool Configuration

After downloading a plugin, you need to configure it. The demo got confused looking for Maven — it did not show in one list, but it is in the Global Tool Configuration. There you give the local Maven path if you already have Maven, or choose "install automatically" — Jenkins downloads it from the Apache server, you pick the version you want, and it builds your application with that version.

14.14.3 Nodes and Clouds

Runner agents attach to Jenkins in Manage Nodes and Clouds. There is a built-in node — the local node. To configure your own, you create a new node, which is a server, or a cloud: you download whichever cloud you want, configure the URL and everything, and then use it. From there you can do remote node monitoring. In the demo, an Amazon EC2 cloud plugin was being installed just to show how it looks — it asks for your instance IP and the S3 instance, whatever you have, and then you configure it. Everything is UI — you do not need to worry, everything is available in Jenkins and it is very straightforward.

14.14.4 Administration and Upgrades

Manage Jenkins also holds admin operations: create users, update users, add security, block GitHub. There is the Jenkins directory location, and execution settings — the demo keeps the maximum parallel executions at two: only two builds run in parallel, more wait in the queue. The quiet period is five minutes, after which the server stops. Upgrades appear there too: most of the time it shows security issues, new plugins, or an older Jenkins version. You can update based on the warnings, or even downgrade — whatever you want. Mostly you will not do this: your infra team does upgrades, and you work in the configuration layer.

14.15 Pipelines vs Freestyle Projects

14.15.1 Project Types

The "New Item" page offers multiple types: freestyle, pipeline, multi-configuration, folder, multi-branch, and organization. Freestyle and pipeline are the most used. Freestyle gives you full freedom — you create however you want. Pipeline is like a pipeline: one stage completes and the next starts, so it suits dependent projects; when multiple projects depend on each other, you put them in a pipeline. Mostly we go for freestyle, and if it does not fit freestyle, we go for pipeline. The others are variations: multi-configuration runs different configurations — one for Android, one for iOS; folder runs a single folder; multi-branch runs multiple branches in a Git directory; organization runs something for the entire organization. Freestyle alone can run five or six projects one by one, easily configured. After selecting freestyle and giving a name, the configuration page opens — everything explained above gets set, and applying it creates the project. An empty freestyle project builds instantly with no work: it says "done" immediately because there is nothing to build.

14.15.2 The Pipeline Script and Its Stages

A pipeline holds the script — Groovy, unless you prefer your own thing — with all steps as stages. The sample pipeline: it uses any agent, uses Maven M3 (the demo machine has Maven 2), has a build stage that pulls the code, starts Maven, and cleans the package; if the clean is successful, it runs a JUnit test; then it creates the jar file in the target. That is the same logic as the POM file, expressed as stages.

Applying and building the sample fails: the console says "M3 not configured — tool type Maven does not have an installation", exactly the global-tool problem. The demo then tried a minimal hello-world pipeline — one stage — and it worked.

The major difference between pipeline and freestyle is the UI: the pipeline gives a beautiful UI with multiple greens — stage complete, stage complete — like a heartbeat for you as it goes on. With freestyle you can only see what happened in the console output. That is the only major difference.

14.15.3 The Jenkinsfile

For this project a Jenkinsfile also exists, similar to the pipeline script: poll every 10 minutes, disable concurrent builds, use JDK 8, use a Docker agent because the project builds a jar and runs it in a container, go to the M2 directory, set a timeout of 30 minutes after which it should stop, execute run.sh, and in the post section send a message in Slack — something like "danger" or "good" — and send an email. The post section runs after the test stages.

14.15.4 Student Questions: Pipelines, Tests, and Agents

14.16 The Git Merge Problem

14.16.1 The Scenario: Two Developers, One Line

This question came from a candidate: two developers are working on the same line. One guy has totally removed the other guy's line and added something completely new in its place.

14.16.2 Why Every Automated Tool Fails

Asked what to do in this situation, the answer is simple to state and hard to do: none of the automated tools help.

Git cannot decide which line to keep, so the automated tools will fail for this.

14.16.3 The Manual Merge

The only way it works: you manually change. You manually add both lines and commit them as a single commit. You cannot even squash or do anything else — you need to do it manually. And the fix is a team conversation: you need to discuss with each other. Communication is very, very important; you need to do it yourself only.

14.16.4 Why Teams Avoid Overlapping Stories

This is the main reason why, in a particular sprint, the Scrum Master or the Product Owner does not let two people work on similar functionality that touches the same method: two developers should not work on the same method. In the extreme case where it happens anyway, manual merge is the only fix. If somebody in the future asks you to have two developers work on the same thing, explain this problem — and do not take similar stories in the same sprint.

Exam Guidance Summary

• The quiz covers Maven and Jenkins only. Focus on the POM file structure, the Maven commands, the cron fields, and the Jenkins configuration concepts from this session.
• On the war-versus-jar question: Jenkins is executed with the jar command; its internal packaging is war. The quiz answer is jar (the confusion in the quiz was flagged for correction).
• Versioning must be known properly to release: 1.0.0 to 2.0.0 is a major change, 1.0.0 to 1.1.0 is a minor enhancement, 1.0.0 to 1.0.1 is an immediate patch. Giving the wrong version misleads customers.
• The five cron fields are minute, hour, day of month, month, and day of week — with the ranges 0–59 minutes, 24-hour clock hours, 1–31 days, 1–12 months, and day names for the week field.
• The five Jenkins build triggers: trigger builds remotely, build after other projects (stable only), build periodically, GitHub hook trigger, and poll SCM — the hook is the efficient, resource-saving way.
• A DevOps engineer should know the monitoring and analytics tools even though they are not covered in depth here, and should know the versioning semantics, the testing tool landscape, and the lint tools per platform.
• The course DevOps process concludes with this session; there is one more tutorial session next month, and remaining doubts can be sent by mail.

Key Industry Applications

• Real-world: CI/CD loops exactly like the one built today — Java project, Maven build, Jenkins deploy, JUnit test — are the standard pattern in industry for Java and Spring Boot services.
• Real-world: the two deployment paths — direct web-server deployment and marketplace packaging (APK for Android, IPA for iOS, WAR, JAR, EXE, DMG, PKG) — explain why one codebase ships to the App Store, Google Play, and company web servers.
• Real-world: App Store and Play Store "minimum version" messages are the build settings of a POM in the wild; the Android version range shows source-and-target thinking.
• Real-world: Flutter's single codebase for all platforms is the analogy for Maven's uniform build across Windows, Mac, Linux, and the cloud.
• Real-world: fat jars like the shade jar appear wherever teams ship self-contained executables; the Docker container idea is the same dependency isolation philosophy.
• Real-world: the .M2 repository is the shared dependency cache that CI machines rely on; clearing it breaks other projects and wastes network bandwidth.
• Real-world: GitHub hook triggers and polling are the standard ways production Jenkins farms start builds only when code changes.
• Real-world: Jenkins plugin marketplace covers Ant, Apache, Pipelines, JavaDoc, Docker, Kubernetes, email, and cloud agents such as Amazon EC2 — matching the tool stack of real deployment environments.
• Real-world: Slack notifications and email post-build actions in Jenkinsfiles are the everyday way teams get build status pushed to them.
• Real-world: the Git same-line merge problem is why scrum teams assign non-overlapping stories, and why the merge is manual when overlap happens anyway.