I am trying to create a docker image from within maven which includes artifacts from a different maven project. But the examples I have copied do not appear to be working.
I think the problem here is I do not really understand how assemblies work and so am asking for help on what I want to do here. I have set up a contrived simple example of what I am trying to do here:
https://github.com/sodved/java-docker-demo/tree/0.0.1-0
pom.xml
sod-java/pom.xml
sod-java/src/main/java/sodved/Sod.java
sod-docker/pom-depency.xml
sod-docker/pom.xml
sod-docker/src/main/docker/setup.sh
sod-docker/src/main/docker/Dockerfile
sod-docker/src/main/docker/run.sh
So my project has two modules:
/tmp/sod.txt
)/tmp/sod.txt
/tmp/sod.txt
fileI have tried two approaches to the inline <assembly>
so far:
dependecySet
in the assembly. But I noted that the dependency was not even included in the /target
folder (I assume because there is no actual java code to compile in sod-docker, so the dependencies were not copied)./target
folder (which worked). Then used file
in the assembly to try and copy the file.In both cases I do not see the jar file copied anywhere by the assembly or in the tar file which the docker plugin creates and so I get an error when attempting to reference the jar in a Dockerfile COPY
command.
I know the example is a bit contrived. But its simple and fitting with the standard way we do things at work. So I do not have a lot of flexibility in respect to tools, layouts etc.
The real case is used to build database images. Get base image, run java code to manipulate database, save as new image to be used downstream.
TLDR: How can I specify a groupId, artifactId, version and have the corresponding artifact included in my docker image. The docker source itself contains no java.
OK, have figured it out.
The issue was that the pom.xml specified some external configuration
<external>
<type>properties</type>
<prefix>docker</prefix>
<mode>override</mode>
</external>
But as the doco here (http://dmp.fabric8.io/#property-configuration) says, this means the <build>
configuration (including my assembly) in the pom.xml will be ignored. I am not sure why our standard uses the external configuration, will chase up our ops people on that. But removing this <external>
section and everything works.