Separate out project dependencies, add integration test to verify

[loosebazooka]

Uh so here's the PR with the weirdo test. Basically injecting a task to inspect the layer configuration state and outputting it so the test can pick it up and verify. I don't know how else to do it without mocking the world.

[chanseokoh]

jib-gradle-plugin/src/test/resources/gradle/projects/multi-service/complex-service/libs/dependency-1.0.0.jar
jib-gradle-plugin/src/test/resources/gradle/projects/multi-service/complex-service/libs/dependencyX-1.0.0-SNAPSHOT.jar

There files are added accidentally, aren't they? (Note multi-service, not all-local-multi-service.)

[loosebazooka]

There files are added accidentally, aren't they? (Note multi-service, not all-local-multi-service.)

oh right yeah. I'll clean that up. I'm mostly curious what people think of this test.

[chanseokoh]

How about these?

1. We already have code that opens an image tar, goes through all the layers inside the tar (the code assumes all .tar.gz files in the image tar are layer tars), opens the embedded layer tars, and lists all the files in each layer:
   https://github.com/GoogleContainerTools/jib/blob/v1.3.0-maven/jib-core/src/integration-test/java/com/google/cloud/tools/jib/api/ReproducibleImageTest.java#L137
   We won't be able to explicitly verify layer types this way, but I think it is enough to check the order of dependency layers.

2. Or add some code somewhere to log files in each layer as DEBUG.

[loosebazooka]

What about a task _jibDebugShowBuildConfiguration or something instead of (2).

[chanseokoh]

I actually prefer (1). It doesn't look crazy, we already have the code, and it doesn't add any new production code. To me, _jibDebugShowBuildConfiguration seems more code to maintain.

[TadCordle]

Also running tasks/goals in tests is a pretty big slow down, which can be annoying.

[loosebazooka]

Well I still need to load the project context which is what I'm explicitly testing here. I can trust (from gradle) that JavaContainerBuilder is doing the right thing. What I need to know is that the gradle plugin code is doing the right things splitting the dependencies.

[loosebazooka]

Pushed a new less ridiculous test.

[chanseokoh]

This is unclear, but should we do filter(File::exists)? For what I know, if do the filtering for allFiles and classesOutputDirectories. (JavaContainerBuilder does the check and throws NoSuchFileException, which might be a good thing actually. It's unclear to me if this can ever happen.)

[loosebazooka]

Yeah I think it's safer to not filter, if we have an issue in the configuration, it should pick it up. File::exists will just quietly ignore the error.

[chanseokoh]

This looks good. I think the test worked out nicely.