Configuration settings for development environment

Description of the issue: In development environment (esp, in cases like mine where I use Spring Boot), I wouldn’t’ want to deploy my container to see the code changes. I would rather prefer hot-deploy, with the volume in the container pointing to my development directory to skip deployment step and boost developer productivity.

Expected behavior: There doesn’t seem to be scope for it in Jib or am I missing something, here in the docs?

Steps to reproduce: Not Applicable

Environment: Irrelevant

jib-maven-plugin Configuration:

PASTE YOUR pom.xml CONFIGURATION HERE

jib-gradle-plugin Configuration:

PASTE YOUR build.gradle CONFIGURATION HERE

Log output:

Additional Information:

[chanseokoh]

Sorry, I did not mean using Dockefile. You don’t need this. Here, mounting a volume is a runtime thing, and it is just that various runtimes (the Docker engine, Kubernetes, etc) provide ways to mount volumes at runtime. When creating/building an image, you don’t want to fixate how exactly volumes will be mounted at runtime. The example docker run -v above is an example when the runtime to run your image is the Docker engine.

Are you recommending me the extraDirectories attribute in the Jib doc as its equivalent?

I’m talking about the volumes attribute. Scroll down the doc more, and you’ll see that. It’ll look like this. (When I was saying “Dockerfile-VOLUME-equivalent”, I meant this attribute will create the same image metadata as what the Dockerfile VOLUME directive will create.) But AFAIK, in this use case, I believe things like docker run -v will work without configuring volumes, which makes sense considering that such volumes are meant only for dev env.

[chanseokoh]

mounting the development directory as readable volume of the container should ideally be a doable thing

This is doable, of course. Nothing prevents you from mounting any directory to an arbitrary location inside an image. However, mounting your source repo won’t magically make your image recompile your source repo. Even if you mount directories containing .class files that are somehow recompiled outside the image, doing so won’t magically make the already running JVM pick up the new .class files and replace previous classes already loaded in the JVM. Therefore, the point of the hackery in that blog was to blatantly override the entrypoint of an image and instead run entr for the sake of watching file changes of a source repo to trigger a full rebuild (mvn clean compile) and run the recompiled app (mvn java:exec) whenever entr detects file changes. To emphasize again, for the idea of directly mounting a source repo to work as you wish, you must override the entrypoint of an image anyway, not to mention that you have to watch file changes, re-trigger full builds, and re-launch another JVM each time, ignoring what the image is designed to do.

But I can tell you there exists a far much better (and simple) way to achieve what you really want: Java remote debugging. You are probably aware that when you launch a simple debug session in an IDE, whenever you change your source code in the IDE, the changes become effective instantly on the running app in the debug session. Essentially, you’ll do the same thing in your case. Whether your app is running inside an image or not is irrelevant; as long as you connect your IDE debugger to the running app, you’ll instantly have the same degree of productivity from instant class reloading. Not only is this approach much more superior to the file-change-watch-and-full-rebuild-and-JVM-relaunch hackery in terms of productivity, it will result in working with the same prod image on your dev environment. Moreover, it will allow setting breakpoints, stepping on your code, etc. If you haven’t known, it is easy to set up this remote debug. You pass some argument to your JVM, and make your debugger connect to it through the configured port. Take a look our FAQ and articles like https://jaxenter.com/remote-debugging-java-applications-151466.html. (You may find better articles when googling “java remote debug”.)