jib-core v0.19.0

Major Changes

• JavaContainerBuilder#fromDistroless() and JavaContainerBuilder#fromDistrolessJetty() are deprecated. To migrate, check the Javadoc. (#3123)
• For Google Artifact Registry (*-docker.pkg.dev), Jib now tries Google Application Default Credentials last like it has been doing for gcr.io. (#3241)
• Timestamps of file entries in a built TarImage are set to the epoch, making the tarball reproducible. (#3158)

See CHANGELOG.md for more details.

jib-maven-plugin v3.1.1

Major Changes

• Fixed the regression introduced in 3.1.0 where a build may fail due to an error from main class inference even if <container><entrypoint> is configured. (#3295)

See CHANGELOG.md for more details.

jib-gradle-plugin v3.1.1

Major Changes

• Fixed the regression introduced in 3.1.0 where a build may fail due to an error from main class inference even if jib.container.entrypoint is configured. (#3295)

See CHANGELOG.md for more details.

jib-maven-plugin v3.1.0

Major Changes

• For Google Artifact Registry (*-docker.pkg.dev), Jib now tries Google Application Default Credentials last like it has been doing for gcr.io. (#3241)
• Jib now creates an additional layer that contains two small text files: /app/jib-classpath-file and /app/jib-main-class-file. They hold, respectively, the final Java runtime classpath and the main class computed by Jib that are suitable for app execution on JVM. For example, with Java 9+, setting the container entrypoint to java --class-path @/app/jib-classpath-file @/app/jib-main-class-file will work to start the app. (This is basically the default entrypoint set by Jib when the entrypoint is not explicitly configured by the user.) The files are always generated whether Java 8 or 9+, or whether jib.container.entrypoint is explicitly configured. The files can be helpful especially when setting a custom entrypoint for a shell script that needs to get the classpath and the main class computed by Jib, or for AppCDS. (#3280)
• For Java 9+ apps, the default Java runtime classpath explicitly lists all the app dependencies, preserving the dependency loading order declared by Maven. This is done by changing the default entrypoint to use the new classpath JVM argument file (basically java -cp @/app/jib-classpath-file). As such, <container><expandClasspathDependencies> takes no effect for Java 9+. (#3280)
• Timestamps of file entries in a tarball built with jib:buildTar are set to the epoch, making the tarball reproducible. (#3158)

See CHANGELOG.md for more details.

jib-gradle-plugin v3.1.0

Major Changes

• For Google Artifact Registry (*-docker.pkg.dev), Jib now tries Google Application Default Credentials last like it has been doing for gcr.io. (#3241)
• Jib now creates an additional layer that contains two small text files: /app/jib-classpath-file and /app/jib-main-class-file. They hold, respectively, the final Java runtime classpath and the main class computed by Jib that are suitable for app execution on JVM. For example, with Java 9+, setting the container entrypoint to java --class-path @/app/jib-classpath-file @/app/jib-main-class-file will work to start the app. (This is basically the default entrypoint set by Jib when the entrypoint is not explicitly configured by the user.) The files are always generated whether Java 8 or 9+, or whether jib.container.entrypoint is explicitly configured. The files can be helpful especially when setting a custom entrypoint for a shell script that needs to get the classpath and the main class computed by Jib, or for AppCDS. (#3280)
• For Java 9+ apps, the default Java runtime classpath explicitly lists all the app dependencies, preserving the dependency loading order declared by Gradle. This is done by changing the default entrypoint to use the new classpath JVM argument file (basically java -cp @/app/jib-classpath-file). As such, jib.container.expandClasspathDependencies takes no effect for Java 9+. (#3280)
• Timestamps of file entries in a tarball built with jibBuildTar are set to the epoch, making the tarball reproducible. (#3158)
• Added lazy evaluation for jib.container.labels using Gradle Property and Provider. (#3242)

See CHANGELOG.md for more details.

jib-cli v0.6.0

Major Changes

• Added automatic update check. Jib CLI will now display a message if a new version is available. See the privacy page for more details. (#3165)
• Added --image-metadata-out option to specify the JSON output file that should contain image metadata (image ID, digest, and tags) after build is complete. (#3187)

See CHANGELOG.md for more details.

jib-maven-plugin v3.0.0

Major Changes

• Switched the default base images from Distroless to adoptopenjdk:{8,11}-jre and jetty (for WAR). (#3124)
• New <includes> and <excludes> options for <extraDirectories>. This enables copying a subset of files from the source directory using glob patterns. (#2564)
• Jib extensions can be loaded via the Maven dependency injection mechanism. This also enables injecting arbitrary dependencies (for example, Maven components) into an extension. (#3036)
• Fixed an issue where some log messages used color in the "plain" console output. (#2764)

See CHANGELOG.md for more details.

jib-gradle-plugin v3.0.0

Major Changes

• Switched the default base images from Distroless to adoptopenjdk:{8,11}-jre and jetty (for WAR). (#3124)
• New includes and excludes options for jib.extraDirectories. This enables copying a subset of files from the source directory using glob patterns. (#2564)
• Added an option configurationName to specify the name of the Gradle Configuration to use. The option can be lazily configured, for example, using Gradle Provider or Property. (#3034)

    jib {
      configurationName = 'myconfig'
    }

• Fixed an issue where some log messages used color in the "plain" console output. (#2764)

See CHANGELOG.md for more details.

jib-cli v0.5.0

Major Changes

• Fixed an issue where critical error messages (for example, unauthorized access from a registry) were erased by progress reporting and not shown. (#3148)

See CHANGELOG.md for more details.

jib-cli v0.4.0

Major Changes

• Added support for configuring registry mirrors for base images. This is useful when hitting Docker Hub rate limits. Only public mirrors (such as mirror.gcr.io) are supported. (#3134)

See CHANGELOG.md for more details.