If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/GoogleContainerTools/jib shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 3w ago
• 29+ active contributors
• Distributed ownership (top contributor 29% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live GoogleContainerTools/jib repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/GoogleContainerTools/jib.

What it runs against: a local clone of GoogleContainerTools/jib — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in GoogleContainerTools/jib | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 48 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of GoogleContainerTools/jib. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/GoogleContainerTools/jib.git
#   cd jib
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of GoogleContainerTools/jib and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "GoogleContainerTools/jib(\\.git)?\\b" \\
  && ok "origin remote is GoogleContainerTools/jib" \\
  || miss "origin remote is not GoogleContainerTools/jib (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".github/workflows/unit-tests.yml" \\
  && ok ".github/workflows/unit-tests.yml" \\
  || miss "missing critical file: .github/workflows/unit-tests.yml"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "STYLE_GUIDE.md" \\
  && ok "STYLE_GUIDE.md" \\
  || miss "missing critical file: STYLE_GUIDE.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 48 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~18d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/GoogleContainerTools/jib"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Jib is a Maven/Gradle plugin and standalone Java library that builds optimized Docker and OCI container images for Java applications without requiring a Docker daemon. It automatically layers applications (dependencies separate from classes) to enable fast, reproducible deployments by rebuilding only changed layers rather than entire images. Monorepo with independent plugins: jib-maven-plugin/ and jib-gradle-plugin/ are build-system-specific entry points that delegate to jib-core/ (the core container-building library), plus jib-cli/ for standalone CLI usage. examples/dropwizard/ demonstrates real-world usage. Build is Gradle-based (build.gradle at root) with shared config in config/checkstyle/ and CI workflows in .github/workflows/.

Java developers and DevOps engineers who want to containerize applications quickly without Docker expertise or daemon management—especially those using Maven or Gradle build systems, and teams deploying to Google Cloud Build or Kubernetes.

Production-ready and actively maintained. The project has stable badges, Maven Central and Gradle Plugin Portal distribution, multi-platform CI (Linux/Windows/macOS via Kokoro), SLSA Level 3 provenance, and is backed by Google Cloud Tools. Commits are recent and issue response is active.

Low risk for core functionality. Dependencies are well-maintained (Google guava, jackson, commons-compress, oauth libraries) and vendored versions are pinned. The monorepo structure (jib-maven-plugin, jib-gradle-plugin, jib-core, jib-cli) is mature, but contributing directly requires understanding multiple build systems. No obvious single-maintainer risk given Google backing.

Recent work includes dependency updates (Jackson 2.15.2, Guava 32.1.2-jre, Commons Compress 1.26.0), zstd compression support (zstd-jni 1.5.5-5), YAML configuration via jackson-dataformat-yaml, and active CI validation via Sonar, unit-tests, and release pipelines. Release checklists in .github/RELEASE_TEMPLATES/ indicate ongoing versioning cadence across three components.

git clone https://github.com/GoogleContainerTools/jib.git
cd jib
./gradlew build
# For Maven plugin: cd jib-maven-plugin && ../gradlew build
# For Gradle plugin: cd jib-gradle-plugin && ../gradlew build
# For CLI: cd jib-cli && ../gradlew build

Daily commands:

# Build all modules
./gradlew build

# Run tests
./gradlew test

# Code quality checks
./gradlew check

# Format code
./gradlew googleJavaFormat

# Publish locally
./gradlew publishToMavenLocal

• build.gradle — Root build configuration defining plugin versions, dependency management, and build orchestration for all Jib modules (Maven, Gradle, CLI).
• README.md — Project overview and quick-start guide explaining Jib's core purpose: containerizing Java applications without Docker daemon.
• .github/workflows/unit-tests.yml — CI/CD pipeline configuration validating builds across Linux, Windows, and macOS—critical for understanding test execution and release gates.
• CONTRIBUTING.md — Contribution guidelines covering pull request process, code standards, and project governance for external contributors.
• STYLE_GUIDE.md — Coding standards and conventions (checkstyle, formatting, naming) enforced across the 600-file codebase.
• config/checkstyle/checkstyle-suppressions.xml — Checkstyle rules and suppressions that enforce code quality and consistency across all source files.
• .github/dependabot.yml — Automated dependency version management strategy ensuring security and compatibility of transitive dependencies.

Add a new Gradle example project

1. Create new example directory under examples/ with standard Gradle structure (examples/newexample/build.gradle)
2. Configure Gradle wrapper and settings.gradle following helloworld pattern (examples/newexample/settings.gradle)
3. Add Jib plugin configuration in build.gradle with image name and registry settings (examples/newexample/build.gradle)
4. Create sample Java application source under src/main/java/example/ (examples/newexample/src/main/java/example/Application.java)
5. Document the example in examples/newexample/README.md explaining framework integration (examples/newexample/README.md)

Add a new Maven example project

1. Create new example directory under examples/ with standard Maven structure (examples/newexample/pom.xml)
2. Configure Jib Maven plugin in <plugins> section with image name and registry configuration (examples/newexample/pom.xml)
3. Set up Maven wrapper scripts (mvnw/mvnw.cmd) in example root directory (examples/newexample/mvnw)
4. Create sample Java application source under src/main/java/example/ (examples/newexample/src/main/java/example/Application.java)
5. Document the example in examples/newexample/README.md with Maven-specific build instructions (examples/newexample/README.md)

Update project dependencies and release

1. Update dependency versions in the project.ext.dependencyStrings map in build.gradle (build.gradle)
2. Run ./gradlew check to validate builds pass across all modules (build.gradle)
3. Follow the appropriate release checklist (core/plugin/cli) from .github/RELEASE_TEMPLATES/ (.github/RELEASE_TEMPLATES/core_release_checklist.md)
4. The prepare-release.yml workflow will automatically bump versions and create release commit (.github/workflows/prepare-release.yml)

• Gradle & Maven plugins — Jib is primarily distributed as build tool plugins to integrate seamlessly into existing Java build pipelines without requiring Docker CLI or daemon
• Container registry APIs (Docker Registry, GCP, ECR, etc.) — Jib pushes images directly to registries using OCI image format, eliminating Docker daemon dependency for containerization
• Layer-based image caching — Jib's core innovation: separates dependencies, resources, and classes into independent layers with smart caching to reduce rebuild time and bandwidth
• Java base images (distroless, JDK) — Default base images optimized for Java with minimal footprint; users can customize via configuration
• Gradle wrapper validation & dependabot — Ensures reproducible builds and automated security updates for transitive dependencies across multi-module project

• Plugin-first architecture (Gradle/Maven) rather than standalone CLI

  • Why: Tightest integration with existing Java build workflows; minimal additional setup for users already using Gradle/Maven
  • Consequence: Users who don't use Gradle/Maven (or use atypical setups) must use the separate Jib CLI tool; increases maintenance burden of supporting multiple distribution channels

• Direct registry push without Docker daemon

  • Why: Faster builds, lower resource footprint, no daemon dependency, simplified CI/CD
  • Consequence: More complex image format handling in Jib code; fewer debugging tools available if image building fails (can't inspect intermediate state locally)

• Layer-based caching strategy with heuristic ordering (dependencies → resources → classes)

  • Why: Maximizes cache reuse for common Java rebuild patterns where classes change frequently but dependencies rarely do
  • Consequence: Inflexible for non-standard project layouts; users with custom build structures may not see optimal caching benefits

• Multi-module monorepo (core, Maven plugin, Gradle plugin, CLI) with shared build.gradle

  • Why: Single source of truth for versions and policies; coordinated releases ensure compatibility across tooling
  • Consequence: Complex build graph and interdependencies; changes to core library require rebuilding and retesting all plugins; slower incremental development

• Does not replace or wrap Docker; Jib is a library/plugin that generates OCI images directly
• Does not provide container orchestration (Kubernetes, Swarm); only handles image building and pushing
• Does not support non-JVM languages or applications outside the Java ecosystem
• Does not handle container runtime configuration (networking, volumes, secrets); that's left to deployment tools
• Does not provide a GUI; interaction is via CLI tools (Gradle, Maven, Jib CLI) or configuration files
• Does not support OCI image signing at build time; signing is delegated to registry or external tools

No Docker daemon required: Jib pushes directly to registries; local Docker CLI is optional. Checkstyle strict: code formatting failures block builds; run ./gradlew googleJavaFormat before commit. Multi-module Gradle: subprojects inherit parent config; version changes must be coordinated across jib-maven-plugin, jib-gradle-plugin, jib-core, jib-cli. Extension API versioning: jib-build-plan, jib-plugins-extension-common, jib-gradle-plugin-extension-api, jib-maven-plugin-extension-api are separate published artifacts with their own SemVer; mismatches break plugin loading. Reproducibility matters: tests validate deterministic image hashing; timing/ordering changes in layer generation can break reproducibility contracts.

• Image Layering (Layer Separation Strategy) — Jib's core value is splitting dependencies, resources, and classes into independent layers so only changed layers rebuild; understanding layer order and cacheability is critical to using Jib effectively
• OCI Image Spec & Docker Image Format — Jib outputs valid OCI and Docker v2.2 manifests, including JSON config blobs and tar layer archives; contributors must understand image serialization format to add new features
• Registry Authentication (OAuth2 / Credential Helpers) — Jib handles GCP service accounts, Docker config.json, oauth2 tokens, and private registry auth; the jib-core/registry module abstracts credential resolution and is often a source of user issues
• Reproducible Builds & Deterministic Timestamps — Jib strips timestamps and sorts entries to ensure identical image SHA256 hashes across rebuilds (critical for security scanning and artifact verification); this constraint affects any layer generation code
• Build Plan Abstraction (Extension API) — Jib exposes its build intent via com.google.cloud.tools:jib-build-plan; plugins and extensions can inspect/modify the plan before execution, enabling custom base images and layer injection
• Incremental Builds & Layer Caching — Jib's fast deploy claim relies on registries caching unchanged layer digests; understanding Docker image cache keys and cross-build caching behavior is essential for troubleshooting slow rebuilds
• Gradle/Maven Plugin Lifecycle Integration — jib-maven-plugin hooks into Maven's package phase, jib-gradle-plugin defines custom tasks; contributors must understand how plugin metadata is discovered and how configuration is bound to Mojo/Task classes

• GoogleContainerTools/kaniko — Alternative daemonless container builder for Kubernetes; solves same problem (no Docker daemon) but for Go/general binaries rather than Java-specific optimization
• buildpacks/pack — Alternative declarative image builder using buildpacks abstraction; competes on ease of Java containerization but less control over layer structure than Jib
• moby/buildkit — Modern Docker build engine that Jib could integrate with; BuildKit is the lower-level alternative to jib-core's image serialization for advanced caching
• GoogleCloudPlatform/cloud-builders — Google Cloud Build container images; Jib integrates directly here for CI/CD (see docs/google-cloud-build.md); users running Jib in Cloud Build reference these builders
• docker/docker-java — Java Docker client library that Jib could use for daemon interaction; instead Jib bypasses daemon entirely and speaks directly to registries

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for jib-cli with various base images and compression formats

The repo has jib-cli as a major component but lacks comprehensive integration tests covering different base image scenarios and the newly added zstd compression (zstd-jni:1.5.5-5 in dependencies). Testing combinations of base images, compression formats, and registry targets would catch regressions early and document CLI behavior.

• [ ] Create new test file in jib-cli/src/test for integration tests
• [ ] Add test cases for zstd compression output validation (see ZSTD_JNI dependency in build.gradle)
• [ ] Add test cases for multiple base image builds (see docs/default_base_image.md)
• [ ] Test CLI with both Docker registry and credentials scenarios (see docs/configure-gcp-credentials.md)
• [ ] Add CI workflow to run these tests in unit-tests.yml or create dedicated workflow

Add GitHub Actions workflow for testing against multiple JVM versions

The repo currently has unit-tests.yml but doesn't test against multiple Java versions (8, 11, 17, 21). Given Jib's role in containerizing Java applications, testing across JVM versions is critical for compatibility. This would catch version-specific issues early.

• [ ] Review existing .github/workflows/unit-tests.yml structure
• [ ] Create new workflow matrix strategy with Java versions 8, 11, 17, 21
• [ ] Test both Gradle and Maven builds across versions (examples/helloworld has both pom.xml and build.gradle)
• [ ] Ensure Google HTTP client and Guava compatibility is validated per JVM version (see GOOGLE_HTTP_CLIENT and GUAVA in dependencies)
• [ ] Add workflow status badge to README.md

Add comprehensive documentation and examples for jib-plugins-extension-api usage

The repo adds BUILD_PLAN, EXTENSION_COMMON, GRADLE_EXTENSION, and MAVEN_EXTENSION dependencies, indicating plugin extension capabilities, but docs/ directory lacks guidance on extending Jib. Creating examples and documentation would help the ecosystem build on top of Jib.

• [ ] Create docs/extending-jib-with-plugins.md explaining the extension API
• [ ] Reference the jib-build-plan:0.4.0 and extension API versions from build.gradle
• [ ] Add a minimal example in examples/ (e.g., examples/custom-extension/) showing a simple extension
• [ ] Document how to use GRADLE_EXTENSION and MAVEN_EXTENSION in plugin build.gradle/pom.xml
• [ ] Add links to extension documentation in main README.md and CONTRIBUTING.md

• Add integration tests for zstd-jni compression in jib-core/src/test/ to validate the newly-added Zstandard compression path (currently dependency is vendored but test coverage is likely incomplete for this bleeding-edge feature).
• Expand examples/dropwizard/ with a Gradle equivalent (currently only Maven pom.xml exists); create examples/dropwizard-gradle/ to demonstrate jib-gradle-plugin with the same application, mirroring Maven example structure.
• Document registry credential precedence and environment variable handling in docs/configure-gcp-credentials.md; currently unclear whether GOOGLE_APPLICATION_CREDENTIALS or jib's built-in auth takes priority across different registries (GCR vs. Docker Hub vs. private).

The Jib codebase demonstrates a generally solid security posture with proper security reporting procedures (g.co/vulnz) and SLSA 3 compliance. However, there are moderate concerns around dependency versions: Jackson BOM (2.15.2) and several other dependencies could be updated to newer stable versions with security patches. The project shows good security practices with published SECURITY.md and evidence of CI/CD security checks (.allstar/binary_artifacts.yaml). No hardcoded secrets were detected in the provided file structure. Recommendations focus on dependency version management and keeping build tools current. The incomplete JACKSON_DATATYPE_JSR declaration should be reviewed to ensure the build configuration is complete and correct.

• Medium · Outdated Jackson Dependencies — build.gradle - JACKSON_BOM: 'com.fasterxml.jackson:jackson-bom:2.15.2'. Jackson BOM version 2.15.2 is used, which may contain known vulnerabilities. Jackson 2.15.2 was released in 2023 and newer versions with security patches are available. Consider upgrading to the latest stable version. Fix: Update Jackson BOM to the latest stable version (2.17.x or newer) to include security patches and bug fixes.
• Low · Google HTTP Client Library Version — build.gradle - GOOGLE_HTTP_CLIENT: 'com.google.http-client:google-http-client:1.42.2'. google-http-client version 1.42.2 is moderately old. While not critically outdated, newer versions may contain security improvements and bug fixes. Fix: Review and upgrade to the latest stable version of google-http-client to ensure all security patches are applied.
• Low · Guava Dependency Version — build.gradle - GUAVA: 'com.google.guava:guava:32.1.2-jre'. Guava version 32.1.2-jre is used. While relatively recent, verify it matches the google-shared-dependencies BOM recommendations mentioned in the comments for best compatibility and security. Fix: Verify the Guava version against https://github.com/googleapis/java-shared-dependencies to ensure compatibility and security alignment.
• Low · Apache Commons Compress Version — build.gradle - COMMONS_COMPRESS: 'org.apache.commons:commons-compress:1.26.0'. commons-compress version 1.26.0 is used. While current, verify it has no known CVEs as compression libraries are frequently targeted. Fix: Periodically check CVE databases (NVD, Snyk) for commons-compress vulnerabilities and upgrade as needed.
• Low · Incomplete Dependency Declaration — build.gradle - JACKSON_DATATYPE_JSR (incomplete). The JACKSON_DATATYPE_JSR dependency definition appears to be truncated or incomplete in the provided file, which could indicate a build configuration issue. Fix: Verify the complete dependency declaration for JACKSON_DATATYPE_JSR and ensure all dependencies are fully defined.
• Low · SonarQube Version — .github/workflows and build.gradle - org.sonarqube version 4.0.0.2929. SonarQube plugin version 4.0.0.2929 is used. Verify this version is actively maintained and not outdated. Fix: Check SonarQube plugin release notes and update to the latest version if security updates are available.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.