Jib: Way to exclude dependencies in the image or have right support for various forms of fat/shaded JARs

Created on 17 Jul 2019  路  4Comments  路  Source: GoogleContainerTools/jib

Hi again,

When building with containerizingMode = 'packaged', our dependencies are built into the jar archive. Is it possible to not add the dependencies to <appRoot>/libs for a smaller image?

Most helpful comment

I replied to #1851 and just saw your comment. The FAQ explains the current limitation of containerizingMode = 'packaged', and currently neither fat JARs nor excluding dependencies as an alternative is not supported yet. Supporting fat JARs created in various ways including by Spring Boot is something on our radar, but we are not sure when we will get to it.

I think I'll open this issue, which asks for either having

  • proper support for fat/shaded JARs created in various ways; or
  • just some means to exclude dependency JARs

Note this issue is not talking about runnable JARs (which are often fat). #530 is the issue for runnable JARs.

All 4 comments

I replied to #1851 and just saw your comment. The FAQ explains the current limitation of containerizingMode = 'packaged', and currently neither fat JARs nor excluding dependencies as an alternative is not supported yet. Supporting fat JARs created in various ways including by Spring Boot is something on our radar, but we are not sure when we will get to it.

I think I'll open this issue, which asks for either having

  • proper support for fat/shaded JARs created in various ways; or
  • just some means to exclude dependency JARs

Note this issue is not talking about runnable JARs (which are often fat). #530 is the issue for runnable JARs.

It is best to avoid putting a fat JAR if possible, because it nullifies all the benefits of fine-grained layering by Jib that brings in fast iterations and caching. It'd be ideal if Jib could just use the original (non-fat) JAR. For Maven, Spring Boot leaves the original JAR in the build directory, so it seems not difficult for Jib to automatically detect Spring Boot and use the original JAR (fixed by #2170). For Gradle, we can enable the jar task disabled by Spring Boot (fixed by #2178).

We may still introduce an option to not copy dependency JARs if we should really copy a fat JAR, but for now, it's worth implementing this auto-detection for Spring Boot.

With new Jib versions, now Spring Boot projects with containerizingMode='package' should work seamlessly for both Gradle and Maven out of the box.

Anyways, I don't think we'll need to provide a general way to exclude adding dependencies into the image for the sake of being able to put a fat JAR (with <containerizingMode>packaged). Now I think almost all the time, we can just put a normal, non-fat JAR (as long as a project generates the normal JAR and we can locate it) regardless of whether maven-shade-plugin, maven-assembly-plugin, or Gradle shadowJar plugin is applied to create a fat JAR.

However, for a potential feature for generalized fined-grained dependency control, see https://github.com/GoogleContainerTools/jib/issues/1962#issuecomment-599235543

However, for a potential feature for generalized fined-grained dependency control, see #1962 (comment)

The Jib Extension Framework is now available with the latest Jib versions. You can easily extend and tailor the Jib plugins behavior to your liking.

We've written a general-purpose layer-filter extension that enables fine-grained layer control, including deleting files and moving files into new layers.

For general information about using and writing extensions, take a look at the Jib Extensions repo.

Was this page helpful?
0 / 5 - 0 ratings