jkube icon indicating copy to clipboard operation
jkube copied to clipboard

Filter for Maven props not working on docker file

Open springframeworkguru opened this issue 4 years ago • 8 comments

Maven Properties not getting substituted as described.

This docker file:

FROM openjdk:11-jre-slim as builder
WORKDIR application
ADD maven/${project.build.finalName}.jar ./${project.build.finalName}.jar
RUN java -Djarmode=layertools -jar ${project.build.finalName}.jar extract

FROM openjdk:11-jre-slim

WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom", "org.springframework.boot.loader.JarLauncher"]

creates this error on build:

[INFO] k8s: Step 3/11 : ADD maven/${project.build.finalName}.jar ./${project.build.finalName}.jar
[INFO] k8s: 
[ERROR] k8s: Failed to execute the build [Error while trying to build the image: Unable to build image [kbe-temp] : "failed to process \"maven/${project.build.finalName}.jar\": missing ':' in substitution" ]

I also tried explicitly setting the filter property to ${*} or @ and no luck.

Info

  • Eclipse JKube version : 1.2.0
  • Maven version (mvn -v) : 3.8.1

  • Kubernetes / Red Hat OpenShift setup and version : n/a

  • If it's a bug, how to reproduce : mvn k8s:build

  • Sample Reproducer Project : https://github.com/springframeworkguru/kbe-rest-brewery/tree/jkube (use jkube branch w/above docker file)

springframeworkguru avatar May 14 '21 21:05 springframeworkguru

I can reproduce this issue. While debugging, I am not able to see project.build.finalName property being set here:

https://github.com/eclipse/jkube/blob/f5069b21b03ecc9672c96e5cf812c20a36897622/jkube-kit/build/api/src/main/java/org/eclipse/jkube/kit/build/api/helper/DockerFileUtil.java#L129-L132

When I explicitly set this property like this:

diff --git a/pom.xml b/pom.xml
index f6f7c5a..f5f0116 100644
--- a/pom.xml
+++ b/pom.xml
@@ -28,6 +28,7 @@
         <java.version>11</java.version>
         <mapstruct.version>1.4.2.Final</mapstruct.version>
         <org.lombok.version>1.18.18</org.lombok.version>
+        <project.build.finalName>${project.artifactId}-${project.version}</project.build.finalName>
     </properties>

mvn k8s:build builds successfully

rohanKanojia avatar May 17 '21 15:05 rohanKanojia

fyi - I have a cleaner example on branch jkube-broken

https://github.com/springframeworkguru/kbe-rest-brewery/tree/jkube-broken

springframeworkguru avatar May 17 '21 16:05 springframeworkguru

I see similar behavior on jkube-broken too. If I manually set project.build.finalName in <properties> it works. Looks like jkube is not taking standard maven properties into account.

rohanKanojia avatar May 17 '21 16:05 rohanKanojia

Thanks @rohanKanojia . Not sure if its helpful, works fine with the fabric8 docker-maven-plugin

Example here https://github.com/springframeworkguru/kbe-rest-brewery/tree/maven-props

springframeworkguru avatar May 17 '21 19:05 springframeworkguru

I'm not sure about this, but Docker Maven Plugin is probably delegating resource filtering to Plexus.

After a thorough analysis, the main issue is that in JKube we are only considering Properties (System, Project, Session, etc.) when performing replacements.

Maven Resources Plugin, which should be our guide, is not only using properties but Object properties to retrieve filtered/interpolated values. It makes use of ObjectBasedValueSource to retrieve values for replacement.

So for example, an expression like project.build.finalName with possible prefixes as ["pom", "project"] can be evaluated in a MavenProject instance as mavenProject.getBuild().getFinalName().

This can be seen while debugging and placing a breakpoint in MultiDelimiterStringSearchInterpolator.java#L238. The valueSources variable will have at least 5 items including encapsulated ObjectBasedValueSource for MavenProject and MavenSession.

At this moment I'm not sure we can provide an easy fix for this that will allow us to have something more generic (i.e. property retrieval via expression evaluations of Objects.).

The suggested workaround would be to encapsulate the required properties in standard Maven properties in your pom.xml:

<properties>
  <myBuildFinalName>${project.build.finalName}</myBuildFinalName>
</properties

manusa avatar May 18 '21 09:05 manusa

@manusa - if this isn't going to be resolved soon, the project documentation should be updated, which specifically refers to project properties.

Replacement includes Maven project properties such as ${project.artifactId}, properties set in the build, command-line properties, and system properties.

See filtering section here.

I was migrating a working example from the docker-maven-plugin and found the behavior confusing.

springframeworkguru avatar May 18 '21 11:05 springframeworkguru

hmm, that's bad.

This is something we can tackle in a future release, but it involves quite a big refactor. I'll strike-through that statement in the docs in the meantime.

manusa avatar May 18 '21 11:05 manusa

hmm, that's bad.

This is something we can tackle in a future release, but it involves quite a big refactor. I'll strike-through that statement in the docs in the meantime.

This is still broken in 1.18.1. And it's the third example I have encountered this afternoon of functionality from docker-maven-plugin dropped contrary to documentation and with misleading error messages. In every case a comment somewhere in the bug thread that documentation will be updated has not being actioned. At this point references in the documentation to docker-maven-plugin, Fabric8, maven-assembly-plugin and even maven-plugin should be removed as extremely misleading. Maybe too much focus on Gradle, Zero-config and Helm support and not enough on don't-break-what-was-working-before. It would also be nice if the vague commentary around XML configuration not being reliable was elaborated upon so we don't need to spend days on trial-and-error build config to see what documented features are actually implemented.

FWIW, THE most used property interpolations in a DockerFile are ${project.artifactId}-${project.version}.jar and ${project.build.finalName}.jar.

dwhitla avatar Sep 23 '25 04:09 dwhitla