GoogleContainerTools/jib · error · IllegalArgumentException

Dependency required by the JAR (as specified in `Class-Path`

Error message

Dependency required by the JAR (as specified in `Class-Path` in the JAR manifest) doesn't exist: ${fullDepPath}

What it means

When containerizing an exploded/fat JAR, Jib reads the `Class-Path` attribute of the JAR manifest to find dependency JARs and adds each as a layer entry. If a referenced dependency file does not exist on disk at the resolved path, addDependency throws this IllegalArgumentException instead of silently producing a broken image.

Source

Thrown at jib-cli/src/main/java/com/google/cloud/tools/jib/cli/jar/JarLayers.java:100

            path ->
                addDependency(
                    snapshotLayer,
                    jarParent.resolve(path),
                    mode.equals(ProcessingMode.packaged)
                        ? APP_ROOT.resolve(path)
                        : APP_ROOT
                            .resolve(ArtifactLayers.DEPENDENCIES)
                            .resolve(path.getFileName())));
        layers.add(snapshotLayer.build());
      }
      return layers;
    }
  }

  private static void addDependency(
      FileEntriesLayer.Builder layerbuilder, Path fullDepPath, AbsoluteUnixPath pathOnContainer) {
    if (!Files.exists(fullDepPath)) {
      throw new IllegalArgumentException(
          String.format(
              "Dependency required by the JAR (as specified in `Class-Path` in the JAR manifest) doesn't exist: %s",
              fullDepPath));
    }
    layerbuilder.addEntry(fullDepPath, pathOnContainer);
  }
}

View on GitHub (pinned to fb949e2676)

Solutions

Restore the missing dependency JAR to the path referenced in the JAR's Class-Path manifest attribute
Run `unzip -p app.jar META-INF/MANIFEST.MF` to inspect Class-Path and verify each path exists relative to the JAR's directory
Rebuild/repackage the JAR so dependencies are present or use a fat JAR without external Class-Path references

Example fix

// before
app.jar            // manifest Class-Path: lib/dep-1.0.jar
lib/               // missing
// after
app.jar
lib/dep-1.0.jar    // dependency restored

Defensive patterns

Strategy: validation

Validate before calling

String cp = manifest.getMainAttributes().getValue(Attributes.Name.CLASS_PATH);
if (cp != null) for (String p : cp.split(" ")) { if (!Files.exists(jarDir.resolve(p.trim()))) throw new IllegalStateException("Missing dep: " + p); }

Try / catch

try { layers = jarProcessor.getLayers(); } catch (IllegalArgumentException e) { if (e.getMessage().contains("Class-Path")) { /* repair deps or repackage */ } }

Prevention

Always distribute the JAR with its full lib/ directory
Verify Class-Path entries resolve relative to the JAR before containerizing
Prefer fat JARs or explicit dependency lists over manifest Class-Path

When it happens

Trigger: Calling JarLayers.getDependenciesLayers on a JAR whose MANIFEST.MF `Class-Path` entry lists a dependency path that does not resolve to an existing file (relative paths resolved against the JAR's directory are missing, moved, or deleted).

Common situations: Copying the JAR without its sibling lib/ directory; the manifest Class-Path built with absolute paths on a different machine; renamed or version-bumped dependency JARs; building a thin JAR outside its original layout.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06). Data as JSON: /api/errors/47b661f6f9733a5f. Report an issue: GitHub.