Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Separate layer for snapshot dependencies in quarkus-container-image-jib

See original GitHub issue

Description I have a multi-module Maven project where a Quarkus application declares snapshot dependencies to the other modules. Currently quarkus-container-image-jib lumps all jar files in target/lib together into a single Docker image layer, including the snapshot jars of my dependent modules. This makes the Docker images much less efficient than what they could be because there is 50 MB of never changing content and a few hundred kilobytes of always changing content in one layer.

As a workaround I attempted to make my snapshot builds reproducible using reproducible-build-maven-plugin, but this effort failed because jandex-maven-plugin does not generate reproducible results. Somebody wanted to make jandex builds reproducible, but that effort seems to be on hold.

Implementation ideas quarkus-container-image-jib should generate a separate layer for jars that have SNAPSHOT in their name. The layer would be directly on top of the dependent libraries layer.

References

Adjacent discussion at #9818.

Issue Analytics

State:
Created 3 years ago
Comments:11 (9 by maintainers)

Top GitHub Comments

1reaction

aloubyanskycommented, Jan 19, 2021

@aloubyansky is there a way we can know from the AppModel whether or not a runtime dependency is part of the “project” or not? getLocalProjectArtifacts maybe?

yes

0reactions

geoandcommented, Jan 19, 2021

Keep in mind that for the time being what you requested will only work when the version of your project (and therefore the dependencies) use the SNAPSHOT in their version.

This restriction might be lifted in later revisions of the code

Top Results From Across the Web

Container Images - Quarkus

The major benefit of using Jib with Quarkus is that all the dependencies (everything found under target/lib ) are cached in a different...

Building a Native Executable - Quarkus

The Quarkus Micro Image is a small container image providing the right set of dependencies to run your native application. It is based...

Native Reference Guide - Quarkus

This guide builds and executes Quarkus native executables within a Linux environment. To offer a homogeneous experience across all environments, the guide ...

All configuration options - Quarkus

AWS Lambda Type Default AWS Lambda Common Type Default AWS Lambda Gateway REST API Type Default Agroal ‑ Database connection pool Type Default

Writing Your Own Extension - Quarkus

Quarkus extensions add a new developer focused behavior to the core offering, and consist of two distinct parts, buildtime augmentation and runtime ...