GoogleContainerTools/jib · error · IllegalArgumentException

`Main-Class:` attribute for an application main class not de

Error message

`Main-Class:` attribute for an application main class not defined in the input JAR's manifest (`META-INF/MANIFEST.MF` in the JAR).

What it means

When using a packaged (non-exploded) standard JAR as the build input, Jib reads `Main-Class` from META-INF/MANIFEST.MF to compose the `java -jar` entrypoint. A missing attribute triggers this IllegalArgumentException in StandardPackagedProcessor.computeEntrypoint.

Source

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

    // Add layer for jar.
    FileEntriesLayer jarLayer =
        FileEntriesLayer.builder()
            .setName(JarLayers.JAR)
            .addEntry(jarPath, JarLayers.APP_ROOT.resolve(jarPath.getFileName()))
            .build();
    layers.add(jarLayer);

    return layers;
  }

  @Override
  public ImmutableList<String> computeEntrypoint(List<String> jvmFlags) throws IOException {
    try (JarFile jarFile = new JarFile(jarPath.toFile())) {
      String mainClass =
          jarFile.getManifest().getMainAttributes().getValue(Attributes.Name.MAIN_CLASS);
      if (mainClass == null) {
        throw new IllegalArgumentException(
            "`Main-Class:` attribute for an application main class not defined in the input JAR's "
                + "manifest (`META-INF/MANIFEST.MF` in the JAR).");
      }
      ImmutableList.Builder<String> entrypoint = ImmutableList.builder();
      entrypoint.add("java");
      entrypoint.addAll(jvmFlags);
      entrypoint.add("-jar");
      entrypoint.add(JarLayers.APP_ROOT + "/" + jarPath.getFileName().toString());
      return entrypoint.build();
    }
  }

  @Override
  public Integer getJavaVersion() {
    return jarJavaVersion;
  }
}

View on GitHub (pinned to fb949e2676)

Solutions

Add `Main-Class` to the JAR manifest in the build tool and repackage the JAR
Provide an explicit entrypoint/args via Containerizer or Jib CLI flags instead of manifest-based inference
Verify the JAR actually has a main class (`unzip -p app.jar META-INF/MANIFEST.MF`) before containerizing

Example fix

// pom.xml (before)
<plugin>maven-jar-plugin, no archive config</plugin>
// after
<archive><manifest><mainClass>com.example.Main</mainClass></manifest></archive>

Defensive patterns

Strategy: validation

Validate before calling

try (JarFile jf = new JarFile(jarPath.toFile())) {
  if (jf.getManifest() == null || jf.getManifest().getMainAttributes().getValue(Attributes.Name.MAIN_CLASS) == null) throw new IllegalStateException("JAR has no Main-Class");
}

Try / catch

try { entrypoint = processor.computeEntrypoint(jvmFlags); } catch (IllegalArgumentException e) { if (e.getMessage().contains("Main-Class")) { entrypoint = userProvidedEntrypoint; } }

Prevention

Set mainClass in maven-jar-plugin or Gradle jar manifest config
Check manifest content after any shading/repackaging step
Provide explicit entrypoints when manifest inference is undesirable

When it happens

Trigger: Calling computeEntrypoint on a packaged standard JAR whose manifest lacks the `Main-Class:` attribute (getValue(Attributes.Name.MAIN_CLASS) returns null).

Common situations: Containerizing a library JAR without a main class; forgetting the jar-plugin manifest configuration; fat JAR repackaging that drops the Main-Class attribute; mismatched processor selection treating the JAR as a standard app.

Understand the failure class

Background: "is required", "must be set", "missing required field": configuration validation errors across open-source libraries — this error's family across 36 libraries.

Related errors

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