mainClass, extraClasspath, jvmFlags, and…

Error message

mainClass, extraClasspath, jvmFlags, and expandClasspathDependencies are ignored for WAR projects

What it means

For WAR projects Jib builds a Jetty-based servlet container image and constructs its own entrypoint (launching the Jetty start.jar); settings like mainClass, extraClasspath, jvmFlags, and expandClasspathDependencies are irrelevant and silently ignored, so Jib warns when they are set.

Solutions

Remove mainClass, jvmFlags, extraClasspath (extraDirectories classpath), and expandClasspathDependencies from the Jib configuration of the WAR project
Use jvmFlagsForJettyRunImage/base image configuration appropriate for WAR deployments if JVM tuning is needed
Set a custom base image if you need a different servlet container entrypoint
Accept the default Jetty entrypoint (java -jar /usr/local/jetty/start.jar --module=ee10-deploy) for WAR images

Example fix

// before (build.gradle, war project)
jib {
  mainClass = 'com.example.Main'
  jvmFlags = ['-Xms512m']
}
// after
jib {
  container { /* WAR project: entrypoint is provided by Jetty base image */ }
}

Defensive patterns

Strategy: validation

Validate before calling

if ("war".equals(project.getPackaging())) {
  // assert Jib java-app options are unset
  if (mainClass != null || !jvmFlags.isEmpty()) {
    System.out.println("WAR project: mainClass/jvmFlags/extraClasspath will be ignored by Jib");
  }
}

Prevention

Keep separate Jib config profiles for jar vs war modules
Remove Java-app entrypoint settings when converting a module to war packaging
Use container.baseImage for custom servlet containers instead of entrypoint-related options

When it happens

Trigger: A WAR-packaging project processed via computeEntrypoint where the raw configuration has a mainClass present, non-empty jvmFlags, a non-empty extraDirectory classpath, or expandClasspathDependencies=true.

Common situations: Copying JVM flags or mainClass settings from a JAR-based Jib configuration into a WAR project; forgetting to remove Java-app entrypoint settings after converting a project from jar to war packaging.

Related errors

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

Appendix: source

Thrown at jib-plugins-common/src/main/java/com/google/cloud/tools/jib/plugins/common/PluginConfigurationProcessor.java:623

      projectProperties.log(
          LogEvent.info(
              "mainClass, extraClasspath, jvmFlags, and expandClasspathDependencies are ignored "
                  + "when entrypoint is specified"));
    }

    if (projectProperties.isWarProject()) {
      if (entrypointDefined) {
        return rawEntrypoint.get().size() == 1 && "INHERIT".equals(rawEntrypoint.get().get(0))
            ? null
            : rawEntrypoint.get();
      }

      if (rawConfiguration.getMainClass().isPresent()
          || !rawConfiguration.getJvmFlags().isEmpty()
          || !rawExtraClasspath.isEmpty()
          || rawConfiguration.getExpandClasspathDependencies()) {
        projectProperties.log(
            LogEvent.warn(
                "mainClass, extraClasspath, jvmFlags, and expandClasspathDependencies are ignored "
                    + "for WAR projects"));
      }
      return rawConfiguration.getFromImage().isPresent()
          ? null // Inherit if a custom base image.
          : Arrays.asList("java", "-jar", "/usr/local/jetty/start.jar", "--module=ee10-deploy");
    }

    List<String> classpath = new ArrayList<>(rawExtraClasspath);
    AbsoluteUnixPath appRoot = getAppRootChecked(rawConfiguration, projectProperties);
    ContainerizingMode mode = getContainerizingModeChecked(rawConfiguration, projectProperties);
    switch (mode) {
      case EXPLODED:
        classpath.add(appRoot.resolve("resources").toString());
        classpath.add(appRoot.resolve("classes").toString());
        break;
      case PACKAGED:
        classpath.add(appRoot.resolve("classpath/*").toString());

View on GitHub (pinned to fb949e2676)