projectDependencies layer is omitted when executing a partial maven build

Environment:

• Jib version: 2.5.2
• Build tool: Maven 3.6.3
• OS: mac os x 10.15.2

Description of the issue: Running Maven with a partial reactor build, e.g. ./mvnw package jib:build -pl name-service in the multimodule-example (https://github.com/GoogleContainerTools/jib/tree/master/examples/multi-module) does add the shared-library.jar to the dependencies or snapshot dependencies layer, but not to the project dependencies layer.

Expected behavior: Reactor dependencies should not be added to the dependencies layer because every change in a reactor module would lead to the recreation of the (usually quite big) dependencies layer.

Steps to reproduce:

1. export PROJECT_ID=<your own Google Cloud Platform project>
2. ./mvnw install -pl !name-service
3. ./mvnw package jib:build -pl name-service OR (if no gcp address) ./mvnw package jib:dockerBuild -pl name-service
4. docker history gcr.io/${PROJECT_ID}/multimodule/name-service:0.1.0
5. ./mvnw install jib:build OR (if no gcp address) ./mvnw install jib:dockerBuild
6. docker history gcr.io/${PROJECT_ID}/multimodule/name-service:0.1.0

Log output: For 4):

➜  multi-module git:(master) ✗ docker history gcr.io/multimodule/name-service:0.1.0 
IMAGE               CREATED             CREATED BY               SIZE                COMMENT
9612edbaf472        50 years ago        jib-maven-plugin:2.5.2   1.45kB              classes
<missing>           50 years ago        jib-maven-plugin:2.5.2   0B                  resources
<missing>           50 years ago        jib-maven-plugin:2.5.2   16MB                dependencies
<missing>           50 years ago        bazel build ...          100MB               
<missing>           50 years ago        bazel build ...          8.41MB              
<missing>           50 years ago        bazel build ...          1.93MB              
<missing>           50 years ago        bazel build ...          15.1MB              
<missing>           50 years ago        bazel build ...          1.79MB          

For 6):

➜  multi-module git:(master) ✗ docker history gcr.io/multimodule/name-service:0.1.0
IMAGE               CREATED             CREATED BY               SIZE                COMMENT
05e4a9e68ba5        50 years ago        jib-maven-plugin:2.5.2   1.45kB              classes
<missing>           50 years ago        jib-maven-plugin:2.5.2   0B                  resources
<missing>           50 years ago        jib-maven-plugin:2.5.2   2.25kB              project dependencies
<missing>           50 years ago        jib-maven-plugin:2.5.2   16MB                dependencies
<missing>           50 years ago        bazel build ...          100MB               
<missing>           50 years ago        bazel build ...          8.41MB              
<missing>           50 years ago        bazel build ...          1.93MB              
<missing>           50 years ago        bazel build ...          15.1MB              
<missing>           50 years ago        bazel build ...          1.79MB              

Additional Information: Problem is in com.google.cloud.tools.jib.maven.MavenProjectProperties#getProjectDependencies which uses session.getProjects() while it should use session.getAllProjects().

[loosebazooka]

So @danielwegener generally maven isn’t great at the multimodule workflows for non lifecycle goals. This is something we, as the jib team, have had to grapple with.

./mvnw package jib:build -pl module-A -am

will try to trigger jib:build on module-A and all of module-A’s project dependencies (which we don’t necessarily want).

There are two options.

1. explicitly configure the jib plugin with <skip>true</skip> on all non-jib projects, which seems like a common pattern in maven multimodule builds.

2. Bind jib:build to the package lifecycle phase on module-A and use

   ./mvnw package -pl module-A -am
   

   This runs regular package on the dependency modules, and additionally run’s jib:build on module-A

both of which are not super ideal, but it is the consequence of maven’s build structure.

The question is then if project dependencies means “dependencies in the same reactor build” or “dependencies from the same multimodule maven project”

To this point, you are right, there is some value is clearing this up. Technically we mean “reactor”.

[chanseokoh]

I don’t know much about --resume-from, but based on what you said, I’ll assume here that it can end up not building some of the sub-modules.

@danielwegener I’d say the behavior isn’t “desired” but an unfortunate limitation due to Maven. Unlike Gradle, Maven doesn’t have a way to trigger running other plugins or some build phases from a plugin. Even for a single-module project, Jib explicitly requires the user to first run mvn compile (or mvn package for the <containerizingMode>packaged mode) so that all the binaries and resources are fully prepared and generated in the output directory. In the same vein, for a multi-module project, the user must first do mvn package (often with -pl and --also-make) to have all the project output in each target/ directories of the sub-modules. It is the user’s responsibility to build each sub-module first; we are not aware of any way to auto-trigger building dependency projects in Maven.

Adding @loosebazooka in case he has other things to say.