GoogleContainerTools/jib · warning

mainClass, extraClasspath, jvmFlags, and expandClasspathDepe

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.

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)

Solutions

  1. Remove mainClass, jvmFlags, extraClasspath (extraDirectories classpath), and expandClasspathDependencies from the Jib configuration of the WAR project
  2. Use jvmFlagsForJettyRunImage/base image configuration appropriate for WAR deployments if JVM tuning is needed
  3. Set a custom base image if you need a different servlet container entrypoint
  4. 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

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.