Maven / Gradle

Maven builds a full dependency graph by resolving each dependency's transitive dependencies recursively. When the same artifact (same groupId:artifactId) appears at multiple versions in the graph, Maven applies two rules: Nearest-wins: the version declared closest to the root project in the dependency tree wins. project → A (1.0) → C (1.5) and project → B (1.0) → C (1.2): if A and B are both direct dependencies (depth 1), C is at depth 2 from both — first declaration in the POM wins (A's path → C 1.5). First-declaration wins (tiebreaker at same depth): the first dependency that brings in a given transitive dep wins. Problems: nearest-wins can silently downgrade a library. If C 1.5 has a security fix and nearest-wins picks C 1.2, your build is vulnerable without any warning. Fix with <dependencyManagement>: Explicitly pin the version of any transitive dependency you care about: xml <dependencyManagement> <dependencies> <dependency> <groupId>com.example</groupId> <artifactId>C</artifactId> <version>1.5</version> </dependency> </dependencies> </dependencyManagement> This wins over all transitive declarations. Gradle: fails on version conflict by default with a clear error. Resolve with resolutionStrategy.force("com.example:C:1.5").

Both run tests, but at different lifecycle phases with different failure semantics: maven-surefire-plugin (unit tests): - Binds to the test phase - By convention, runs classes matching **/*Test.java, **/*Tests.java, **/*TestCase.java - If tests fail, the build fails immediately in the test phase - Does NOT start/stop server infrastructure maven-failsafe-plugin (integration tests): - Binds goals to pre-integration-test, integration-test, and post-integration-test phases (within verify) - By convention, runs classes matching **/*IT.java, **/*ITCase.java - Critical difference: even if integration tests FAIL, the build continues through post-integration-test (allowing cleanup of started servers/containers), then fails in the verify phase - Works with build-helper-maven-plugin to start Testcontainers or embedded servers in pre-integration-test and stop them in post-integration-test

In practice: mvn test runs unit tests. mvn verify runs unit tests + integration tests. CI pipelines typically run mvn verify for full coverage. Separate them to allow fast feedback: mvn test first, then mvn verify -DskipTests (skip unit tests, run only integration tests) in a later CI step.

Gradle marks a task as UP-TO-DATE if none of its declared inputs have changed since the last execution and all declared outputs still exist. If UP-TO-DATE, the task is skipped entirely. How inputs/outputs are declared: - @Input: scalar values (String, Boolean, Enum). Changes trigger re-run. - @InputFile / @InputFiles / @InputDirectory: file content. SHA checksums compared. - @OutputFile / @OutputFiles / @OutputDirectory: expected output files. - @Internal: fields not affecting outputs (e.g., a logger). Not tracked. What breaks incremental builds: 1. Undeclared inputs: a task reads System.getProperty("user.name") but doesn't declare it as @Input. Gradle doesn't know to re-run when the user changes. Result: task stays UP-TO-DATE when it shouldn't. 2. Side effects outside declared outputs: task writes to a file not in @OutputFiles. Another task reading that file won't know the first task changed it. 3. Non-deterministic outputs: tasks that produce different outputs for the same inputs (timestamps in JAR manifests, random ordering) break the build cache (different cache key each run). 4. doLast blocks reading undeclared inputs. Debug: ./gradlew <task> --info shows why a task was not UP-TO-DATE.

Step 1: Profile to find the bottleneck. Maven: mvn install -fae + mvn -Dsurefire.reportFormat=plain verify. Check which phase takes longest. Gradle: ./gradlew build --scan → upload build scan → detailed task timeline. Gradle optimizations: - Enable build cache: org.gradle.caching=true in gradle.properties + remote cache server. CI workers share cached task outputs — if another worker already built the same inputs, the task is fetched from cache (from remote cache = CACHE HIT, skip execution). - Configuration cache: org.gradle.configuration-cache=true. Caches task graph; configuration phase (executing build scripts) is skipped on subsequent runs. - Parallel execution: org.gradle.parallel=true. Independent subproject tasks run in parallel. - Selective builds: in a monorepo, only build modules affected by the change. Use ./gradlew :orders-service:build or a plugin (Gradle Affected Modules).

Maven optimizations: - Parallel: mvn -T 1C install (one thread per CPU core). - Selective builds: -pl changed-module -am (only changed module + dependencies). - Skip unnecessary phases in CI: mvn package -DskipTests for the build step; separate mvn test step. Use -o (offline) when SNAPSHOTs aren't needed. - Daemon: Maven daemon (mvnd) caches the JVM across invocations — significant startup overhead reduction.

Common culprit: network I/O. Use a local Nexus/Artifactory mirror; CI should have a warm dependency cache (mount ~/.m2 or ~/.gradle from a cache volume).

Maven approach: Define all dependency versions in the root parent POM <dependencyManagement>. Child modules declare dependencies WITHOUT <version> — they inherit the version from the parent. This ensures all modules use consistent versions. For third-party library suites (Spring Boot, Spring Cloud, AWS SDK), import their BOMs: xml <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>3.3.1</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> Now no child needs to specify Spring Boot dependency versions — the BOM covers them all. Gradle approach: Use gradle/libs.versions.toml (version catalog): toml [versions] spring-boot = "3.3.1" [libraries] spring-starter-web = { module = "org.springframework.boot:spring-boot-starter-web", version.ref = "spring-boot" } Reference: implementation(libs.spring.starter.web). Type-safe, IDE-autocompleted, centralized. Apply as a platform: implementation(platform(libs.spring.bom)). Dependency updates: automate with Dependabot (GitHub) or Renovate Bot — opens PRs when new versions are available, includes changelog links.

The distinction controls what is exposed on the compile classpath of consumers (modules or projects that depend on your library). implementation: the dependency is used internally. It goes on your compile classpath AND your runtime classpath, but it does NOT go on the compile classpath of modules that depend on you. api: the dependency types appear in your public API (method signatures, return types, field types). It goes on your compile classpath, your runtime classpath, AND the compile classpath of all consumers. Why it matters: kotlin // library-a/build.gradle.kts dependencies { implementation("com.google.guava:guava:32.0-jre") // consumers can't use Guava types api("org.slf4j:slf4j-api:2.0.9") // consumers can use Logger directly } Using implementation where possible: (1) consumers don't accidentally depend on your internal libraries, (2) Gradle can skip recompiling consumers when only an implementation dependency changes (ABI hasn't changed), (3) cleaner dependency graph. Rule of thumb: use implementation unless the type literally appears in your public method signatures or fields. Default to implementation.

Maven Central (via Sonatype) has strict requirements: - Source JAR (-sources.jar) and Javadoc JAR (-javadoc.jar) must be published - All artifacts must be GPG-signed - POM must include: <name>, <description>, <url>, <licenses>, <developers>, <scm> elements

POM configuration: xml <build><plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <executions><execution><goals><goal>jar-no-fork</goal></goals></execution></executions> </plugin> <plugin> <artifactId>maven-javadoc-plugin</artifactId> <executions><execution><goals><goal>jar</goal></goals></execution></executions> </plugin> <plugin> <artifactId>maven-gpg-plugin</artifactId> <executions><execution><goals><goal>sign</goal></goals></execution></executions> </plugin> </plugins></build> Publish workflow: 1. Deploy SNAPSHOT to Sonatype OSS snapshot repo 2. Set release version (remove -SNAPSHOT) 3. mvn clean deploy -Prelease → uploads to Sonatype staging 4. Log into Sonatype Nexus UI → close staging repo → release 5. Syncs to Maven Central within ~30 minutes Modern alternative: use the Central Publishing Portal API or the central-publishing-maven-plugin for a simpler automated workflow.

Problem: 30 services in a monorepo. Running ./gradlew build for all 30 takes 30 minutes. Most commits touch 1–2 services. Solution: affected-module detection + remote build cache Step 1: Remote build cache. All CI runners and developers share a Gradle remote cache (Develocity or self-hosted). org.gradle.caching=true. After the first full build, subsequent builds hit the cache for unchanged modules. CI runner building service-A after another runner already built the same inputs → CACHE HIT, no compilation needed. Step 2: Detect affected modules. Use git diff --name-only origin/main...HEAD to find changed files. Map file paths to Gradle subprojects (:orders-service, :shared-lib). Run only affected subprojects and their dependents: bash ./gradlew :orders-service:build :orders-service:test -amd -amd = also-make-dependents: builds any service that depends on orders-service. Catches regression in consumers of a changed shared library. Step 3: Composite builds for shared libraries. Extract truly shared code (common-lib) into a separate Gradle composite build. It's built independently; services include it. Changes to common-lib trigger rebuilds of all dependent services (via -amd); changes to one service don't trigger common-lib rebuild. Step 4: Configuration cache. org.gradle.configuration-cache=true. Caches the task graph configuration. Build startup drops from 30s to 5s for cached configurations. Result: a PR touching orders-service: builds 1–3 affected modules instead of 30. Cache hit on unchanged modules. Total CI time: 3 min instead of 30 min.

Maven: maven-enforcer-plugin xml <plugin> <artifactId>maven-enforcer-plugin</artifactId> <executions><execution><goals><goal>enforce</goal></goals> <configuration><rules> <bannedDependencies> <excludes> <exclude>commons-logging:commons-logging</exclude> <exclude>log4j:log4j</exclude> </excludes> </bannedDependencies> <requireUpperBoundDeps/> <!-- warn when lower version wins conflict --> <dependencyConvergence/> <!-- fail on any version conflict --> </rules></configuration> </execution></executions> </plugin> Gradle: dependency constraints + resolution rules kotlin configurations.all { resolutionStrategy { failOnVersionConflict() force("org.slf4j:slf4j-api:2.0.9") eachDependency { if (requested.group == "commons-logging") { useTarget("org.slf4j:jcl-over-slf4j:2.0.9") because("Replace commons-logging with SLF4J bridge") } } } } License compliance: - Maven: license-maven-plugin generates license reports; fail on prohibited licenses (GPL in a commercial product) - Gradle: com.github.jk1.dependency-license-report plugin; configure allowed/forbidden licenses OWASP CVE scanning: - Maven: org.owasp:dependency-check-maven → mvn verify -Pcheck fails on CVSS > 7.0 - Gradle: org.owasp.dependencycheck plugin - CI: run on every PR; block merge on HIGH/CRITICAL CVEs

The core problems at scale: - Inconsistent build tooling versions across teams (Maven 3.6 vs 3.9, Java 11 vs 21) - Duplicated build logic (every team writes their own Docker build, GPG signing, Sonar integration) - Slow CI because no shared build cache - Security: old dependencies with CVEs, no license governance Centralized parent POM / convention plugin: Publish a company-parent POM (Maven) or company-conventions Gradle plugin. It encodes: Java version, compiler settings, Checkstyle config, Sonar integration, OWASP dependency check, Enforcer rules (ban old logging frameworks), publishing config. Teams inherit without configuring. Update the parent → all teams get the update on next build. Artifact repository governance (Nexus/Artifactory): - Proxy Maven Central through the internal Nexus — all dependencies go via internal mirror - Curated "approved" group for internal artifacts - Automated CVE scanning on Nexus: quarantine artifacts with CRITICAL CVEs before teams can even download them - License compliance enforced at the proxy layer Shared build cache: Gradle Develocity (formerly Gradle Enterprise) or Gradle Cache Node: - All CI runners push to and pull from shared cache - Developers pull from shared cache — first local build after CI is mostly cache hits - Build scan analytics: which tasks are slowest, which teams have most cache misses Toolchain standardization: - Maven Toolchains or Gradle toolchain support: declare java { toolchain { languageVersion = JavaLanguageVersion.of(21) } } - JDK auto-provisioned by Gradle; no "Java version mismatch" bugs - Foojay toolchain resolver downloads the right JDK automatically Dependency updates automation: - Renovate Bot running org-wide: opens PRs in all repos when deps have new versions - Priority bot: flag CVE-driven updates with P1 label; auto-assign to owning team