make it easy to use a src/main/docker/Dockerfile with property replacement

So along with the ideas behind this for kubernetes yaml files https://github.com/fabric8io/fabric8/issues/5861 - I’m liking the idea of having a simple small default Dockerfile using maven properties; then its a natural place for folks to add any custom commands or environment variables using native docker syntax.

e.g. for an ‘executable jar’ style microservice we could use a standard Dockerfile like this:

FROM fabric8/java-jboss-openjdk8-jdk:1.0.10

ENV JAVA_APP_JAR ${project.build.finalName}.jar

ADD ${project.build.finalName}.jar /app

Or something fairly minimal like that. I’m kinda thinking that if folks choose to just write a small minimal Dockerfile (that mostly defines one or two env vars, defines the distro to add and the base image); they will usually want to use maven property filtering by default.

So having an option to enable & disable maven property filtering if specifying the assembly.dockerFileDir would be great. I wonder if we should just enable it by default?

Incidentally I wonder if we should also default the assembly.dockerFileDir value to something like src/main/docker if no other assembly is specified? Then if there is a suitable Dockerfile in src/main/docker then OOTB folks could run this on their project without changing their pom:

mvn io.fabric8:docker-maven-version:0.14.3:build

Or worst case folks could just create an empty maven plugin configuration:

      <plugin>
        <groupId>io.fabric8</groupId>
        <artifactId>docker-maven-plugin</artifactId>
        <version>0.14.2</version>
      </plugin>

so they can use

mvn docker:build

Am just thinking of the minimal pom.xml changing overhead of adding a simple Dockerfile referencing the projects build artefact; so there’s as little to edit on a project as possible

[rhuss]

Added now property replacement support via #777 and available in 0.21.0.

Documentation is here : https://dmp.fabric8.io/#build-filtering

[rodlogic]

This is also on my radar. Having an external Dockerfile is much cleaner since one doesn’t need to learn a new syntax for creating what ultimately is a Dockerfile. However, being able to replace properties is a must.