Maven and SonarQube for DevOps Engineers - Beginners Guide

Overview of the Maven environment setup section on Windows. Topics include: Java and Eclipse installation; creating the first Maven project using templates (no coding required); understanding Maven coordinates; exploring Maven's default directory structure; learning the build steps (compile, test, build, deploy); and understanding Maven goals before building the first project.

Step-by-step Java installation on Windows: downloading Java SE JDK from oracle.com, selecting the Windows 64-bit package, installing with admin privileges, setting up system environment variables (PATH and JAVA_HOME pointing to the JDK installation directory), and validating the installation using command prompt commands (java -version and javac).

Installing Eclipse IDE on Windows. Download Eclipse (2012 version), run the installer which auto-detects the Java installation path, set up a workspace folder to store Maven projects, and launch Eclipse. Overview of the IDE interface and how to create new Java projects.

Creating a Maven project in Eclipse. Navigate through File > New > Project > Others > Maven Project. Overview of Eclipse interface (Package Explorer, editor, output console). Explanation of archetypes: Maven project templates with default directory structure and sample applications. Select Maven archetype quickstart. Introduction to Maven coordinates (group ID, artifact ID, version) needed for project configuration.

Understanding Maven coordinates: group ID (uniquely identifies the organization/project, typically company URL in reverse format like org.apache.maven), artifact ID (project name, unique within the project), and version (tracks releases and updates; SNAPSHOT indicates pre-production code). These coordinates define how projects are identified and referenced. Real-world examples from Spring Boot packages demonstrate how organizations structure and version their artifacts.

Maven project structure created by the archetype template: src/main/java (application code), src/test/java (test cases), pom.xml (Project Object Model containing project metadata, coordinates, dependencies, and build information), target (generated artifacts), and Eclipse-specific libraries. The template provides sample code (App.java and AppTest.java) demonstrating the default layout.

Build process workflow: compile source code (.java to .class files for both application and test cases), run test cases to verify functionality, create packages (JAR, EAR, WAR files), and optionally deploy to target systems. Demonstrated in Eclipse: right-click project > Run As > Maven Build. Introduction to Maven goals concept for controlling build steps.

Maven goals overview organized within three build lifecycles: clean, default, and site. Key goals explained: clean (remove previous build files), validate (verify project correctness), compile (compile source code), test-compile (compile test code), test (run test cases), package (create JAR/WAR/EAR), verify (check package quality), install (store in local repository), and deploy (push to remote repository). Sequential execution: using a higher-level goal automatically executes all preceding goals (e.g., package executes compile and test automatically). Commonly used combinations: clean compile, clean package, install.

Practical demonstration of executing Maven goals in Eclipse: validate (verify project structure), compile (create .class files in target directory), test-compile (automatically runs compile and compiles test code), test (runs test cases successfully), and clean package (removes previous builds and generates JAR file). Shows how Maven executes previous goals automatically when using higher-level goals, updates timestamps in target directory with each build, and names artifacts using the artifact ID (e.g., firstdemoproject-version.jar). Install and deploy goals deferred for later discussion with repositories.

POM.xml (Project Object Model) overview: fundamental Maven file containing project information and build configuration. Structure includes group ID, artifact ID, version, packaging (defaults to JAR), project name, and properties (compiler version). Dependencies section specifies required packages; adding a dependency automatically downloads it and updates the Maven Dependencies folder. Introduction to transitive dependencies concept through Spring Boot example.

Understanding transitive dependencies: packages required by explicitly declared dependencies, automatically downloaded by Maven. Demonstrated with JUnit and Spring Boot examples—Spring Boot Starter Test brings multiple transitive dependencies without explicit specification. Visible in Maven Dependencies folder and Dependency Hierarchy tab. Transitive dependencies are mandatory for the parent dependency to function.

Maven repositories: local repository (.m2 directory created in user home directory) stores downloaded packages for offline reuse, while Maven Central Repository (remote) is the centralized source. First build pulls required packages from remote to local (slower); subsequent builds use local copies (faster). Some organizations use enterprise repositories for security. Maven install goal adds built packages to local repository. Demonstrated: clean install goal execution, showing jar creation and storage in .m2/repository structure.

Deploy goal overview: copies final packages to remote repository. Reference to Maven Central Repository (repo1.maven.org) where all available packages are hosted. Demonstrated updating pom.xml dependencies to use different package versions (JUnit 4.11 to 3.8); shows how transitive dependencies change per version. Error handling: Maven displays errors when a specified package version doesn't exist in the repository (e.g., JUnit 3.8.2). Packages must exist in Maven Central Repository to be successfully downloaded.

Pushing Maven project to remote repository (GitHub): create GitHub repository, convert local project folder to Git repository using git init, use .gitignore to exclude unnecessary files (target directory, .class, .classpath, .settings). Only src folder, pom.xml, and test cases are needed for DevOps engineer to rebuild. Git workflow: add, commit, set remote origin, and push to GitHub. DevOps engineer can then clone and build using Maven in their environment.

Transitioning from Windows/Eclipse to Linux/DevOps perspective. Setting up AWS EC2 instance for Maven build server: launching Amazon Linux instance (free tier eligible), configuring instance type and tags (maven build server), creating security group (maven SG), generating and downloading key pair for SSH access. Foundation for dedicated Maven installation and DevOps workflow.

Connecting to AWS EC2 Maven instance using MobaXterm/Putty with public IP and downloaded key pair. Default username ec2-user, escalate to root with sudo su -. System requirements: install Java (JDK 1.8) using yum package manager. Set up JAVA_HOME environment variable in bash_profile pointing to JDK installation path, source the profile to activate changes, and verify with echo $PATH.

Maven installation on Linux: download Apache Maven tar.gz package using wget command, extract using tar -xvzf to /opt directory. Set up environment variables in bash_profile: M2_HOME (Maven installation path), M2 (Maven bin directory path), and update PATH variable. Source bash_profile to activate changes. Verify installation with mvn --version command showing Maven home path and Java version.

Building Maven project on Linux: clone GitHub repository using git clone, navigate to project directory containing pom.xml. Execute Maven goals sequentially: validate, compile (creates target directory and .class files), test-compile (compiles test cases), test (runs test cases), package (creates JAR file), install (stores artifact in local .m2 repository). First run pulls packages from Maven Central Repository (~45 seconds); subsequent runs use local repository (faster). Demonstrates that Maven commands only work from pom.xml directory, and shows .m2/repository structure with com/democompany/firstdemoproject artifact storage.

Common Maven commands: mvn clean (removes target directory and previous build artifacts), mvn install (executes all prior goals: validate, compile, test-compile, test, package, verify). Best practice: mvn clean install for building and deploying to local repository. Alternative: mvn clean package when not deploying locally. First build slower (downloads packages from central repository), subsequent builds faster (uses cached local repository). Local repository benefits all projects—shared dependencies reduce build time across projects.

Creating Maven projects from Linux command line using archetypes. Command: mvn archetype:generate displays available archetypes (2899 total). Filtering with grep to find specific archetypes (e.g., maven-archetype-webapp). Interactive prompts: select archetype number, version, group ID, artifact ID, version, and package name. Demonstrated creating "second demo project" as web application archetype. Alternative: direct command with all parameters. Shows how archetype generates pom.xml and src structure with index.jsp for web applications.

Understanding pom.xml structure: model version, group ID, artifact ID, version, packaging (war for web apps, jar default), project name, properties. Dependencies section specifies required libraries (JUnit 4.13). Build section defines plugins that execute goals internally (clean, compiler, surefire for tests, war, install, deploy). Demonstrated: removing JUnit dependency causes build failure when test cases exist; re-adding dependency from Maven repo succeeds. Deleting explicit build plugins still succeeds—Maven pulls latest versions from remote repository. First build slower (remote download), subsequent builds faster (local cache).

Overview of settings.xml as global Maven configuration (unlike project-specific pom.xml). Two locations: Maven installation directory (/opt/apache/maven/conf/settings.xml) containing default values, and user's .m2 directory (recommended for custom settings). settings.xml defines environment-wide values and configurations needed across projects. Foundation for Tomcat deployment configuration.

Deploying Maven WAR application to Tomcat using Maven plugin. Prerequisites: running Maven and Tomcat servers. Configuration steps: (1) Update pom.xml with Tomcat server URL and application path (context); (2) Create settings.xml under .m2 directory with Tomcat server credentials (username/password: admin/admin); (3) Add Tomcat7 plugin to pom.xml. Deploy using mvn tomcat7:deploy command (executes full lifecycle). Verified by accessing deployed application in browser showing index.jsp content. Making code changes and redeploying: sometimes requires manual removal of old deployment before redeploy. Real workflow: code comes from Git to Maven, deployment orchestrated through Jenkins.

Overview of Maven's role in DevOps: instead of manual Maven builds (pull code from Git, build, gather dependencies, run tests, deploy), use Jenkins (continuous integration tool) to automate and orchestrate Maven execution. Introduction to Jenkins-Maven integration for streamlined build pipelines.

Jenkins installation on AWS EC2: launch Amazon Linux instance, install Java 1.8 and set JAVA_HOME, add Jenkins repository and install Jenkins package. Start Jenkins service (runs on port 8080). Access Jenkins via browser (public IP:8080), retrieve admin password from /var/lib/jenkins/secrets/initialAdminPassword. Complete initial setup: install suggested plugins (Git, SSH, Maven), create admin user credentials, configure Jenkins URL. Foundation for integrating Maven builds with continuous integration.

Prerequisites in Jenkins: install Maven plugins (Maven Invoker, Maven Integration). On Maven server: create Jenkins user, add to sudoers with password-less sudo, enable SSH password authentication (edit etc/ssh/sshd_config). In Jenkins: Manage Jenkins > Manage Nodes > New Node. Configure: name (maven build server), executors (5), remote root directory (/home/jenkins), launch method (SSH), host (Maven server private IP), credentials (Jenkins user), non-verify host strategy. Verify successful agent connection via logs showing "agent successfully connected."

Creating first Jenkins job for Maven project: create new Maven job (first-demo-project), restrict execution to Maven build server agent. Configure: Git repository URL (GitHub), branch (master), Maven goals (clean install). Configure Global Tool Configuration (Manage Jenkins): Java path (/usr/lib/jvm/java...), Git path (/usr/bin/git), Maven path (/opt/apache-maven). Jenkins pulls code from Git to agent workspace (/home/jenkins), builds on Maven agent, generates artifacts in target directory. Demonstrates real-world CI/CD: developers push to Git → Jenkins automates build on Maven agent → artifacts generated.

Building second demo project through Jenkins: create GitHub repository for second-demo-project, convert local project to Git repository (git init), push code to remote (git push). Create new Jenkins job restricted to Maven agent, configure Git URL and master branch, execute clean install. Jenkins pulls code, builds on Maven agent, generates WAR file in workspace. Artifacts available for deployment to Tomcat (covered separately in DevOps project).

My Other Courses:

Complete DevOps Course : Click Here To Check

Ansible For DevOps Beginners And System Admins : Click Here To Check

Git and GitHub For DevOps Engineers : Click Here To Check

Linux For DevOps Engineers : Click Here To Check

Stay in touch with us

Follow us on social media to be the first to know about our upcoming courses, free tutorials and a lot of amazing content:

YouTube : Click Here

Facebook : Click Here

LinkedIn : Click Here

Instagram : Click Here

SonarQube overview: static code analysis tool for quality management. Code quality dimensions: bug-free, secure, no duplication, proper testing, low complexity, easy integration. SonarQube components: rules (best practices), database (stores analysis reports), web interface (GUI dashboard), ElasticSearch, SonarScanner (agent scanning source code). Supported: 27+ programming languages. Workflow: SonarScanner collects code info from sonarscanner.properties, pulls applicable rules, runs analysis, generates reports (bugs, vulnerabilities, coverage), publishes to SonarQube server database visible via web interface.

Prerequisites: AWS EC2 instance (t2 small, 2GB RAM minimum), OpenJDK 11, port 9000 open in security group. Download SonarQube (LTA 8.9.2 or latest 9.0.1) from official site. Extract to /opt, create dedicated sonarqube user, change directory ownership. Configure sonar.properties (JDBC settings, database, web port 9000). Start with sonar.sh start as non-root user (ElasticSearch requirement). Verify service running on port 9000. Access via browser (IP:9000), default credentials (admin/admin), change password on first login.

SonarQube dashboard navigation: Projects tab (manual setup, project key, token generation), Issues tab (shows detected problems), Rules (639+ per language with predefined best practices), Quality Profiles (collections of rules by language with default/custom options). Quality Gates: threshold-based criteria (code coverage ≥80%, duplication ≤3%, critical issues ≤10) determining pass/fail. Administration (user/project management, security). Practical demo: clone Maven project, run Maven SonarQube goal with project token, analyze code quality, view detailed issues, switch quality profiles for re-analysis.

Production-ready SonarQube setup with separate PostgreSQL database. Prerequisites: Ubuntu EC2 (t2 small, 2GB RAM), OpenJDK 11. Install PostgreSQL, create database and user (sonar/admin), grant privileges. OS configuration: update sysctl.conf and limits.conf for SonarCube requirements. Download and extract SonarQube, rename directory to sonarqube, update sonar.properties (JDBC URL: localhost:5432, username: sonar, password: admin). Create systemd service file, change ownership to sonar user, start sonar.service. Verify port 9000 active, access GUI, reset admin password.

Integrating SonarQube with Jenkins for automated code quality analysis. Steps: generate authentication token on SonarQube, install SonarQube Scanner plugin on Jenkins, add token as secret text credentials, configure system (SonarQube URL, authentication), install SonarScanner in Global Tool Configuration. Create pipeline job: clone code (Git), build (Maven clean package), run SonarQube analysis (mvn sonar:sonar goal). View detailed reports in SonarQube GUI (bugs, vulnerabilities, code smells, security hotspots). Switch quality profiles to apply different rule sets. Use quality gates for threshold-based pass/fail criteria.