When building with Gradle, include project dependencies in the application layer by default and make it easer to customise their location

[nucatus]

Although the issue is discussed in the #23003 issue, I would like to bring it up since this seem to be, more or less, a deal breaker requirement.

It is pretty common for microservice applications that employ the client-server architecture to expose a lib module that is defined as a subproject of the main application and is used at compile time in both, the server and the client application. This can be, for instance, the model package of the server application, that can be easily shared with the client applications.

In a typical CI/CD flow, you have the main application compiled with every commit in the code base, but the lib module being compiled and published only when changes fall in its realm. Thus, you want to produce the lib artifact only when affected by changes, but keep it as it is otherwise.

In our use case, the majority of the code changes impact the main application, and not the lib. Thus, multiple builds of the main server application should share a common layer of dependencies. However, this is not the case, because gradle will include fresh builds of the subprojects in the dependencies of the parent project, which renders docker layers cache unusable.

The solution, of course, might be a dedicated layer, out of the box, for the gradle subprojects. As I understand, this is not a common ground with the maven infrastructure, but maybe this is a strong use case where we need to favor gradle and at least fix half of the problem.

Also posted the issue on stackoverflow, which comes with a dirty fix.

[wilkinsona]

In addition to packaging them in the application layer by default, we should also update the DSL to allow their layer to be customised more easily.