DevOps Lecture Notes – Maven Build & Repositories

Opening & Class Context

• Session begins with a brief prayer of thanksgiving and a request for wisdom and understanding.

• Instructor continues the “DevOps + Cloud (AWS)” journey, building on 5 prior classes that focused heavily on Git/GitHub.

• Thanksgiving holiday greetings to U.S.-based engineers; reminder to be grateful for family and the opportunity to learn.

Recap – Developer Collaboration & Source Control

• Developers (Paul, Simon, Mary, Shiyama, etc.) write code collaboratively.

• Tools used:

  • Git (installed locally).

  • IDEs such as VS Code.

  • SCM platform → GitHub (remote repos).

• Collaboration enabled by Git features: commits, branches, change-tracking; every teammate’s work is visible.

Typical Git Branches Discussed

• master / main

• development

• stage

  • Each branch serves a lifecycle phase; code eventually flows to the client (e.g.
    PayPal) application servers.

Why Build & Package Code?

• Raw source cannot run directly on customer app servers.

• Needs transformation (compile + package) into deployable artifacts the server runtime understands.

• Build stage therefore follows coding & unit-testing before deployment.

Build Tools Introduced

• Java ecosystem: Maven, Gradle, Ant (focus of class = Maven).

• .NET: MSBuild, NAnt.

• JavaScript: npm, Grunt, Gulp.

• Python: pybuilder.

• Ruby: Rake.

Programming Languages Mentioned

• Java, Python, Node.js, .NET, JavaScript (front-end), etc.

• Landmark environment mainly supports Java projects but also minor .NET, Node.js, Python.

Open-Source vs Free vs Licensed Software

• Open Source: software + source code free (e.g. Git, Maven).

• Freeware: no cost but source closed.

• Licensed/Commercial: paid, closed source.

• Interview prompt: “Explain your experience with open-source technology.” Example answer: Linux, Git, Maven, etc.

Maven Fundamentals

• Apache Maven = open-source, Java-based build & project-management tool.

• Centered on POM (Project Object Model) ⇒ pom.xml.

• Handles:

  • Compilation

  • Unit testing

  • Packaging (JAR/WAR/EAR)

  • Reporting & documentation

• Described as software project management & comprehension tool.

Key XML vs HTML Distinction (needed for pom.xml)

• XML (eXtensible Markup Language)

  • Dynamic; user-defined tags allowed.

• HTML (HyperText Markup Language)

  • Predefined tags (<h1>, <p>, etc.).

Unit Testing Refresher

• Definition: process of writing & running unit-test cases for individual components/lines.

• Responsibility = developers (not DevOps).

• Quantitative rule of thumb: if project has $50\,000$ LOC, expect ≈$50\,000$ unit tests.

• Example Bash test snippet:

if grep -q "Landmark" app.sh; then
  echo "PASSED"
else
  echo "FAILED"
fi

• Selenium introduced as automation framework for UI tests.

Maven Installation Demo (AWS EC2)

1. Requirements

   • AWS account, Security Group with port $22$ open (SSH).

   • Red Hat Enterprise Linux 9 (free-tier eligible) instance.

   • t2.medium (4 GiB RAM) per Maven doc recommendation.

2. Key Steps

# connect
ssh -i key34.pem ec2-user@<PUBLIC-IP>

# prerequisite tools
sudo yum install -y wget unzip git vim nano tree

# install OpenJDK 11+
sudo yum install -y java-11-openjdk

# download & extract Maven 3.9.5
cd /opt
sudo wget https://dlcdn.apache.org/maven/maven-3/3.9.5/binaries/apache-maven-3.9.5-bin.zip
sudo unzip apache-maven-3.9.5-bin.zip
sudo mv apache-maven-3.9.5 maven
sudo rm apache-maven-3.9.5-bin.zip

# environment variables (in ~/.bash_profile)
export M2_HOME=/opt/maven
export PATH=$PATH:$M2_HOME/bin
source ~/.bash_profile

# verify
mvn -version   # shows Maven 3.9.5, Java 11

• Maven home directory /opt/maven contains:

  • bin/ (executables), conf/ (settings.xml), lib/ (JARs).

Maven Project Structure Recap

project/
 ├── pom.xml          # build script
 └── src/
     ├── main/java/...  (source code)
     └── test/java/...  (unit tests)

• Developers must supply all three: source code, unit tests, build script.

POM.xml Highlights (excerpt)

<groupId>com.landmark</groupId>
<artifactId>maven-standalone-app</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>

<properties>
  <maven.compiler.source>1.8</maven.compiler.source>
  <maven.compiler.target>1.8</maven.compiler.target>
</properties>

<dependencies> <!-- e.g. JUnit -->
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13.2</version>
    <scope>test</scope>
  </dependency>
</dependencies>

Dependencies & Plugins Sources

• Searched in order:

  1. Local repository: ~/.m2/repository

  2. Remote/Proxy (e.g. Nexus, Artifactory)

  3. Central: https://repo1.maven.org/ (mvnrepository.com UI)

• First build downloads deps from Central → $\approx 7$ s; subsequent builds read local cache → $\approx 2$ s.

Maven Lifecycles & Goals

• Shortcut: mvn package triggers all earlier goals automatically.

Demo – Building a Stand-Alone App

# clone repo
mkdir ~/java_projects
cd ~/java_projects
git clone https://github.com/landmarktech/maven-standalone-app.git
cd maven-standalone-app

# build JAR
mvn package > build.log

# artifact appears in target/
java -jar target/maven-standalone-app-0.0.1-SNAPSHOT.jar

Output: “Hello Engineers, Welcome to Landmark Technologies DevOps Master Class …”

Performance Observation

• First build: $7.04$ s (dependency download).

• Second build (cached): $1.9$ s.

• Removing ~/.m2/repository forces Maven to download again, re-incurring delay.

Custom Local Repository (Hardening)

sudo vi /opt/maven/conf/settings.xml
# add outside comment block
<localRepository>/tmp/maven_local_repo</localRepository>

• After change, Maven populates new path; protects original home dir from accidental deletion.

Artifact Types Explained

• JAR (Java ARchive) → stand-alone CLI/service.

• WAR (Web ARchive) → needs servlet container (Tomcat, Jetty).

• EAR (Enterprise ARchive) → aggregates multiple modules; for full Java EE servers.

• Analogous to general archive formats (.zip, .tar.gz).

AWS Instance Sizing & Cost Note

• Demo switched from t2.micro (1 GiB) to t2.medium (4 GiB) per official Maven memory suggestion.

• More instances = more $$ cost; terminated unused EC2s.

Miscellaneous Tools Mentioned

• Selenium – UI test automation (dependency snippet shown).

• Log4j – logging framework (dependency snippet shown).

• Tree – CLI directory visualizer used to show project structure.

Interview Q&A Nuggets

• “What kind of projects do you support?” → “Primarily Java-based applications; we also handle occasional .NET, Node.js, Python micro-services.”

• “Why Maven?” → “Open-source, standard project model, handles full lifecycle from compile to deploy, rich dependency management.”

• Difference between open-source, freeware, licensed software (see earlier section).

Ethical / Practical Implications Discussed

• Prefer open-source when security & support allow → cost savings & visibility.

• Always unit-test before sending code to clients – prevents production defects.

• Use proper instance sizing; shut down unused resources to save company money.

Common Commands Cheat-Sheet

# build lifecycle
mvn validate | compile | test | package | install | deploy | clean

# view Maven version
mvn -version

# examine last 20 lines of build log
tail -20 build.log

# delete local repo (forces fresh dependency download)
rm -rf ~/.m2/repository

Time-zone Adjustment Command (Demo)

sudo timedatectl set-timezone America/New_York

Live Q&A Highlights

• Why start a new EC2 instead of upgrading? → Simpler demo + memory requirement.

• Will plugins be cached across different projects? → Yes, if same coordinates (groupId/artifactId/version).

• Clarified JDK ≡ Java Development Kit; installing java-11-openjdk satisfies Maven prerequisite.

End of comprehensive notes covering every concept, example, command, and implication shared in the session.