java.nio.file.NotDirectoryException: <some>.jar is not a directory

Environment:

• Jib version: 2.4.0
• Build tool: Gradle
• OS: MacOS

Description of the issue:

I’m getting the following error:

 java.nio.file.NotDirectoryException: <some>.jar is not a directory

when I’m trying to copy specific files using extraDirectories.

I want to “translate” the following instruction from Dockerfile:

COPY application/build/libs/my-app-*.jar /usr/src/app/application.jar

with:

extraDirectories {
        paths {
            file("$buildDir/libs/").eachFileMatch(~/my-app-.*\.jar/) { match ->
                path {
                    from = file("$buildDir/libs/$match.name")
                    into = '/usr/src/app/application.jar'
                }
            }
        }
}

Am I missing anything?

Expected behavior:

The image is successfully built, and files are copied successfully.

[chanseokoh]

I don’t really know much about Spring Boot. Do you want to bake the YAML and log configuration files into the image at compile-time, or do you plan to dynamically supply them at runtime? (I will assume the former.)

Basically, Jib copies what Gradle recognizes; Jib asks Gradle what are compiled Java source files, project resource files, dependencies, etc. So, for example, if you have src/main/resources/foo/bar.txt, then Jib will copy it to <app root>/resources/foo/bar.txt in an image (where <app root> is /app by default). Similarly, .class files will be copied into /app/classes/... in an image. And both /app/classes and /app/resources will be on the runtime classpath, so normally, Java applications have no problem accessing resource files as long as they are accessed through the usual classpath mechanism.

For example, I had an experience using src/main/resources/application.properties in a Spring Boot project a long time ago. The sample repo in the comment is now gone, but I had no issue retrieving a property value from application.properties in the application.

That said, if your config files are not recognized by Gradle as part of a Java project (e.g., getting it from an external source that Gradle doesn’t know about), then you will probably need to use jib.extraDirectories (similar to the Java agent JAR).

Lastly, I think Spring Boot will probably expect to see those config files at a pre-defined location, but I think Spring Boot must have a mechanism to designate a different location at runtime (e.g., setting system properties, environment variables, or command-line options).

[chanseokoh]

dd-java-agent-*.jar is dynamic and is determined according to the build number.

I’ll assume that dd-java-agent-*.jar (whether its name is dynamically determined or not) is not a dependency (whether direct or transitive) of your project and that the agent JAR is not required to compile your project. That is, the agent JAR is basically independent of your project and you just obtain it from an external source during build, for example. (I’m trying to clarify the situation because if it were a dependency JAR of your project, Jib would copy it anyway.)

If so, I think it is right that you need to copy the agent JAR yourself using the jib.extraDirectories feature. But as I said, unfortunately the feature requires you to prepare a directory. For example, you can copy the agent JAR into a new directory, say, $buildDir/jib-extras/dd-java-agent.jar (easily doable in Gradle) and set

jib.extraDirectories { paths = "$buildDir/jib-extras" }

, which will copy all the contents of $buildDir/jib-extras (only dd-java-agent.jar in this case) into the root of the image by default. Alternatively, if you are OK with committing the agent JAR into your source repo, placing it at src/main/jib/dd-java-agent.jar is enough, as src/main/jib is the default extra directory if nothing is configured.

And yes, I think setting jvmFlags as you did will work. Jib will then construct an image entrypoint like

java -Xms1024m -javaagent:./dd-java-agent.jar -cp /app/resources:/app/classes:/app/libs/* your.MainClass

. You don’t need to think about constructing an entrypoint or copying an application JAR yourself; Jib will do the right thing. FYI, technically, Jib does not make use of or copy a packaged application JAR; it rather copies individual .class files, all the dependency JARs, resource files, etc. to create an optimized image and runs your application via java -cp <classpath> your.MainClass instead of java -jar. If you want, you can entirely skip packaging an application JAR altogether when using Jib (which will make your image building marginally faster).

Lastly, here’s a bit related Jib example that dynamically downloads a Java agent when building an image.