Add possibility to add dependencies to the image about docker-maven-plugin HOT 4 CLOSED

One way to achieve this goal would be to not build an uberjar and to supply a Dockerfile of your own, which disables the plugin's logic of trying to generate one for you.

You can use the maven-dependency-plugin to copy all of your dependencies to a directory, such as target/lib:

<plugin>
  <artifactId>maven-dependency-plugin</artifactId>
  <version>2.10</version>
  <executions>
    <execution>
      <phase>prepare-package</phase>
      <goals>
        <goal>copy-dependencies</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <useBaseVersion>false</useBaseVersion>
    <overWriteReleases>false</overWriteReleases>
    <overWriteSnapshots>true</overWriteSnapshots>
    <includeScope>runtime</includeScope>
    <outputDirectory>${project.build.directory}/lib</outputDirectory>
  </configuration>
</plugin>

and then configure the maven-jar-plugin to add a classpath entry to the jar's manifest that also refers to target/lib:

<plugin>
  <artifactId>maven-jar-plugin</artifactId>
  <version>2.6</version>
  <configuration>
    <archive>
      <addMavenDescriptor>true</addMavenDescriptor>
      <manifest>
        <addClasspath>true</addClasspath>
        <classpathPrefix>lib/</classpathPrefix>
        <mainClass>${jar.entrypoint}</mainClass>
      </manifest>
    </archive>
  </configuration>
</plugin>

Your Dockerfile should then copy the contents of target/lib into the image, and also the jar containing your project's source code:

COPY target/lib /usr/share/your-service/lib
COPY target/your-jar.jar /usr/share/your-service/your-jar.jar

Finally, the entrypoint to your image would basically just run java -jar /path/to/your.jar:

ENTRYPOINT ["/bin/bash", "-c", "exec /usr/bin/java $JVM_DEFAULT_ARGS $JVM_ARGS -jar /usr/share/your-service/your-jar.jar \"$@\"", "bash"]

Since each new command in the Dockerfile creates a new layer, this results in the layer containing your project JAR (which conceivably changes on each commit) to a layer containing just your project's dependencies (which conceivably change much less often).

This is the basic strategy that most of the images that we build internally in Spotify use.

from docker-maven-plugin.

@jorgemoralespou What kind of dependencies are you looking to add, eg debian packages or jars?

from docker-maven-plugin.

Maven compile and runtime dependencies, that is jar files.

Today, I'm using spring-boot and fat-jars but that means that every docker image has a new layer with a 38MB jar. That's spring, jetty, camel, guava and more. These normally do not change. And my microservice is only 28Kb. This is what's really changed.

From another maven docker plugin

1.1. Building Images
One purpose of this plugin is to create Docker images holding the actual application. This is done with the docker:build goal. It is easy to include build artifacts and their dependencies into an image. Therefore, this plugin uses the assembly descriptor format from the maven-assembly-plugin to specify the content which will be added from a sub-directory in the image (/maven by default). Images that are built with this plugin can be pushed to public or private Docker registries with docker:push.
https://fabric8io.github.io/docker-maven-plugin/

from docker-maven-plugin.

@mattnworb you should consider adding this ^ to README, as I'm sure a lot of users would like to build a self contained image with all dependencies included.

Great job btw :)

from docker-maven-plugin.