Reverse order of classpath to allow patching

[tobad357]

Description of the issue:
Overriding dependency classes is impossible due to classpath order when generating
startup command.

Sometimes it is necessary to patch a class in the dependencies.
To get this to work the classpath would need to load application classes first and then
lib classpath

Current Entrypoint
ENTRYPOINT ["java","-Xms512m","-Xdebug","--spring.config.name","${APP_NAME}","--spring.config.location","${CONFIG_FILES}","-cp","/app/libs/*:/app/resources/:/app/classes/","com.app.AppStart"]

Expected behavior:
The app classes dir would be first in the classpath
ENTRYPOINT ["java","-Xms512m","-Xdebug","--spring.config.name","${APP_NAME}","--spring.config.location","${CONFIG_FILES}","-cp","/app/resources/:/app/classes/:/app/libs/*","com.app.AppStart"]

Steps to reproduce:

1. Build any project with gradle jibExportDockerContext
2. View the generated Dockerfile

Environment: gradle

[coollog]

Hi @tobad357 , thanks for the suggestion! This definitely sounds like a useful feature and we will have this patched for the next version release (0.9.9).

[coollog]

Hi @tobad357 , we have reversed the classpath order in version 0.9.9 - let us know if this works for you.

[anuraaga]

Thanks for fixing this issue - I can confirm the change fixed a similar problem I was having (I guess there are many jars out there specifying a file tls.crt...).

However, I notice that now the order is resources -> classes -> libs. While there's no official standard, from what I understand, it's more conventional to do classes -> resources -> libs. I've confirmed that this is the order the Gradle application plugin's run task uses, so seems like it might be better to match that behavior?

[coollog]

Hi @anuraaga thanks for the tip! We were thinking to keep resources before classes in case one wished to replace some class file in classes with a file in resources, whereas the reverse does not seem to be of any use (replacing resource file with file in classes). However, mimicking the behavior of the run task may be the right way to go @GoogleContainerTools/java-tools

[briandealwis]

I think your reasoning makes sense @coollog.

[TadCordle]

Agreed, I think we gain more here the way we currently have it vs following convention.

[coollog]

Closing unless any objections to keeping it the way it is.

[anuraaga]

Feel free to keep this closed :) Just want to ask for one more thought though. Currently, this means that users could see different behavior when using gradle's run (which is commonly used from normal IntelliJ running with the Gradle runner) and docker run of a jib image. It's also different than gradle's distribution plugin which runs a jar - the jar packages classes before resources so the JRE will prefer classes. Basically, any Gradle user is highly likely to currently rely on behavior that prioritizes classes over resources regardless of their running / deployment strategy.

I think it can be very surprising to users to see different behavior for run and docker run and might reduce trust in the plugin. I'd recommend giving one more look from a user's perspective - if this Gradle plugin decides not to match Gradle's behavior, I would at least think that should be mentioned in the README.

[briandealwis]

Although the Maven exec:java doesn't add resources to the classpath by default, when configured to do so (addResourcesToClasspath=true) then it adds resources, then classes, then dependencies.