Add scope+include/exclude support in mojo

[rmannibucau]

Description of the issue:

all dependencies of the mojo are added to the images

Expected behavior:

dependencies should be filterable, common way for maven is

1. scope
2. explicit includes/excludes (g:a:v[:t:c])

[briandealwis]

@rmannibucau Jib resolves dependencies using ResolutionScope.RUNTIME_PLUS_SYSTEM, which includes compile, runtime, and system dependencies, which should handle includes and excludes too. Are you seeing a case where dependencies are being unexpectedly included?

[rmannibucau]

Yes,

1. I can use test scope and want to include it in a docker (qa etc)
2. I can exclude some deps from the pom (licensing, mutilple versions, ...)
3. I can need a dep to compile but not want to deliver it - generally provided scope, good example is lombok or autovalue

At the end it can be solved by duplicating poms but since it is 1. common in mbn plugin and 2. as trivial as a filter in a stream, i really think it is worth adding it built in. Workatound is indeed to use jib core in a main and run it with mvn exec plugin.

[briandealwis]

@rmannibucau Jib doesn't package <scope>provided</scope> dependencies. I think you could accomplish your other needs with existing Maven constructs, such properties, profiles, and dependency exclusions? Having different classpaths for the artifact (e.g., as seen by exec:java) vs the packaged image doesn't seem desirable.

I think we'd need a real use case where either the existing constructs cannot work or where using the existing constructs leads to an undesirable situation.

[rmannibucau]

Yep, your proposal is basically the not desired duplication of the poms. My use case is for a pluggable system (a bit like OSGi) where depending the environment the deps are not exactly the same. I use maven to resolve them all and i'd like jib executions to have different includes/excludes. For now I did it customizing my layers with jib programamtically but having it built-in would be nicer.

[natlovewy2535]

คำอธิบายของปัญหา :

การพึ่งพาทั้งหมดของโมโจจะถูกเพิ่มเข้าไปในภาพ

พฤติกรรมที่คาดหวัง :

ควรขึ้นอยู่กับการกรองกรองวิธีทั่วไปสำหรับ maven คือ

1. ขอบเขต
2. ชัดเจนรวม / ไม่รวม ( g:a:v[:t:c])

[chanseokoh]

At the end it can be solved by duplicating poms but since it is 1. common in mbn plugin and 2. as trivial as a filter in a stream, i really think it is worth adding it built in. Workatound is indeed to use jib core in a main and run it with mvn exec plugin.

You don't need to duplicate poms. The usual way is to create multiple Maven profiles (dev, qa, staging, prod, etc.).

Otherwise, when it comes to the built-in filtering support, I think we can close this as a dup in favor of others for supporting fine-grained control over dependencies and layers. See

#1962 (comment)
#403 (comment)
#403 (comment)
#403 (comment)
#403 (comment)
#1436 (comment)
#1852
#2450 (comment)

We expect to support the generalized fined-grained dependency control through the Jib extension framework: #1962 (comment)

[rmannibucau]

For reference profiles is not an option cause it requires rebuilds and is not release compatible whereas multiplying artificially modules work but slows down the build with no gain (why bypassing jib plugin to use core programmatically is saner).

[chanseokoh]

@rmannibucau @natlovewy2535

As promised, 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. The extension will cover your use-case to filter unwanted dependencies (or any files).

• Maven Layer-Filter Extension
• Gradle Layer-Filter Extension

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