carlossg / docker-maven

Official Docker image with Maven

docker-maven

Supported tags and respective Dockerfile links

Images are published under:

• csanchez/maven
• maven (linux and extending Docker official images only)
• ghcr.io/carlossg/maven (linux only)

Linux Based Images

See Docker Hub or GitHub Container Registry for an updated list of tags

• openjdk-8 (deprecated)
• openjdk-8-slim (deprecated)
• openjdk-11 (deprecated)
• openjdk-11-slim (deprecated)
• openjdk-17 (deprecated)
• openjdk-17-slim (deprecated)
• openjdk-18 (deprecated)
• openjdk-18-slim (deprecated)
• eclipse-temurin-8
• eclipse-temurin-8-alpine
• eclipse-temurin-8-focal
• eclipse-temurin-11
• eclipse-temurin-11-alpine
• eclipse-temurin-11-focal
• eclipse-temurin-16
• eclipse-temurin-16-alpine
• eclipse-temurin-17
• eclipse-temurin-17-alpine
• eclipse-temurin-17-focal
• eclipse-temurin-21
• eclipse-temurin-21-alpine
• eclipse-temurin-21-jammy
• eclipse-temurin-22
• eclipse-temurin-22-alpine
• eclipse-temurin-22-jammy
• ibm-semeru-11-focal
• ibm-semeru-17-focal
• ibm-semeru-21-jammy
• ibmjava-8
• amazoncorretto-8
• amazoncorretto-8-al2023
• amazoncorretto-8-debian
• amazoncorretto-11
• amazoncorretto-11-al2023
• amazoncorretto-11-debian
• amazoncorretto-17
• amazoncorretto-17-al2023
• amazoncorretto-17-debian
• amazoncorretto-21
• amazoncorretto-21-al2023
• amazoncorretto-21-debian
• sapmachine-11
• sapmachine-17
• sapmachine-21

Only under csanchez/maven and ghcr.io/carlossg/maven:

• azulzulu-8
• azulzulu-8-alpine
• azulzulu-11
• azulzulu-11-alpine
• azulzulu-17
• azulzulu-17-alpine
• azulzulu-21
• azulzulu-21-alpine
• graalvm-community-17
• graalvm-community-21
• libericaopenjdk-11
• libericaopenjdk-11-alpine
• libericaopenjdk-17
• libericaopenjdk-17-alpine
• libericaopenjdk-8
• libericaopenjdk-8-alpine
• microsoft-openjdk-11-ubuntu
• microsoft-openjdk-17-ubuntu
• microsoft-openjdk-21-ubuntu
• oracle-graalvm-17
• oracle-graalvm-21

Windows Based Images

See Docker Hub csanchez/maven for an updated list of tags

• openjdk-8-windowsservercore-1809 (deprecated)
• openjdk-8-nanoserver (deprecated)
• openjdk-11-windowsservercore-1809 (deprecated)
• openjdk-11-nanoserver (deprecated)
• amazoncorretto-8-windowsservercore-1809
• amazoncorretto-11-windowsservercore-1809
• amazoncorretto-17-windowsservercore-1809
• amazoncorretto-8-al2023
• amazoncorretto-11-al2023
• amazoncorretto-17-al2023
• amazoncorretto-21-al2023
• azulzulu-11-windowsservercore-1809
• azulzulu-17-windowsservercore-1809

What is Maven?

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.

How to use this image

You can run a Maven project by using the Maven Docker image directly, passing a Maven command to docker run:

Linux

docker run -it --rm --name my-maven-project -v "$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.3-jdk-8 mvn verify

Windows

docker run -it --rm --name my-maven-project -v "$(Get-Location)":C:/Src -w C:/Src csanchez/maven:3.3-jdk-8-windows mvn verify

Windows

docker run -it --rm --name my-maven-project -v "$(Get-Location)":C:/Src -w C:/Src maven:3.3-jdk-8-windows mvn clean install

Building local Docker image (optional)

This is a base image that you can extend, so it has the bare minimum packages needed. If you add custom package(s) to the Dockerfile, then you can build your local Docker image like this:

docker build --tag my_local_maven:3.9.6-jdk-8 .

Multi-stage Builds

You can build your application with Maven and package it in an image that does not include Maven using multi-stage builds.

# build
FROM maven
WORKDIR /usr/src/app
COPY pom.xml .
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.1.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

# package without maven
FROM openjdk
COPY --from=0 /usr/src/app/target/*.jar ./

Reusing the Maven local repository

The local Maven repository can be reused across containers by creating a volume and mounting it in /root/.m2.

docker volume create --name maven-repo
docker run -it -v maven-repo:/root/.m2 maven mvn archetype:generate # will download artifacts
docker run -it -v maven-repo:/root/.m2 maven mvn archetype:generate # will reuse downloaded artifacts

Or you can just use your home .m2 cache directory that you share e.g. with your Eclipse/IDEA:

docker run -it --rm -v "$PWD":/usr/src/mymaven -v "$HOME/.m2":/root/.m2 -v "$PWD/target:/usr/src/mymaven/target" -w /usr/src/mymaven maven mvn package

Packaging a local repository with the image

The $MAVEN_CONFIG dir (default to /root/.m2 or C:\Users\ContainerUser\.m2) could be configured as a volume so anything copied there in a Dockerfile at build time is lost. For that reason the dir /usr/share/maven/ref/ (or C:\ProgramData\Maven\Reference) exists, and anything in that directory will be copied on container startup to $MAVEN_CONFIG.

To create a pre-packaged repository, create a pom.xml with the dependencies you need and use this in your Dockerfile. /usr/share/maven/ref/settings-docker.xml (C:\ProgramData\Maven\Reference\settings-docker.xml) is a settings file that changes the local repository to /usr/share/maven/ref/repository (C:\Programdata\Maven\Reference\repository), but you can use your own settings file as long as it uses /usr/share/maven/ref/repository (C:\ProgramData\Maven\Reference\repository) as local repo.

COPY pom.xml /tmp/pom.xml
RUN mvn -B -f /tmp/pom.xml -s /usr/share/maven/ref/settings-docker.xml dependency:resolve

To add your custom settings.xml file to the image use

COPY settings.xml /usr/share/maven/ref/

For an example, check the tests dir

Running as non-root (not supported on Windows)

Maven needs the user home to download artifacts to, and if the user does not exist in the image an extra user.home Java property needs to be set.

For example, to run as the current user (instead of root), mounting the host Maven repo (at ~/.m2)

docker run -v ~/.m2:/var/maven/.m2 -it --rm -u $(id -u) -e MAVEN_CONFIG=/var/maven/.m2 maven mvn -Duser.home=/var/maven archetype:generate

Image Variants

The maven images come in many flavors, each designed for a specific use case.

maven:<version>

This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.

Installed Packages

The following packages are currently installed in each variant. Some come from the parent images and some are installed in this image for backwards compatibility.

	git	curl	tar	bash	which	gzip	procps	gpg	ssh
amazoncorretto-8		✔️	✔️	✔️	✔️	✔️		✔️
amazoncorretto-8-al2023		✔️	✔️	✔️	✔️	✔️		✔️
amazoncorretto-8-debian			✔️	✔️	✔️	✔️
amazoncorretto-11		✔️	✔️	✔️	✔️	✔️		✔️
amazoncorretto-11-al2023		✔️	✔️	✔️	✔️	✔️		✔️
amazoncorretto-11-debian			✔️	✔️	✔️	✔️
amazoncorretto-17		✔️	✔️	✔️	✔️	✔️		✔️
amazoncorretto-17-al2023		✔️	✔️	✔️	✔️	✔️		✔️
amazoncorretto-17-debian			✔️	✔️	✔️	✔️
amazoncorretto-21		✔️	✔️	✔️	✔️	✔️		✔️
amazoncorretto-21-al2023		✔️	✔️	✔️	✔️	✔️		✔️
amazoncorretto-21-debian			✔️	✔️	✔️	✔️
azulzulu-8		✔️	✔️	✔️	✔️	✔️	✔️
azulzulu-8-alpine		✔️	✔️	✔️	✔️	✔️	✔️
azulzulu-11		✔️	✔️	✔️	✔️	✔️	✔️
azulzulu-11-alpine		✔️	✔️	✔️	✔️	✔️	✔️
azulzulu-17		✔️	✔️	✔️	✔️	✔️	✔️
azulzulu-17-alpine		✔️	✔️	✔️	✔️	✔️	✔️
azulzulu-21		✔️	✔️	✔️	✔️	✔️	✔️
azulzulu-21-alpine		✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-8	✔️	✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-8-alpine		✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-8-focal	✔️	✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-11	✔️	✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-11-alpine		✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-11-focal	✔️	✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-17	✔️	✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-17-alpine		✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-17-focal	✔️	✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-21	✔️	✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-21-alpine		✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-22-jammy	✔️	✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-22	✔️	✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-22-alpine		✔️	✔️	✔️	✔️	✔️	✔️
eclipse-temurin-22-jammy	✔️	✔️	✔️	✔️	✔️	✔️	✔️
graalvm-community-17		✔️	✔️	✔️	✔️	✔️		✔️
graalvm-community-21		✔️	✔️	✔️	✔️	✔️		✔️
ibm-semeru-11-focal	✔️	✔️	✔️	✔️	✔️	✔️	✔️
ibm-semeru-17-focal	✔️	✔️	✔️	✔️	✔️	✔️	✔️
ibm-semeru-21-jammy	✔️	✔️	✔️	✔️	✔️	✔️	✔️
ibmjava-8		✔️	✔️	✔️	✔️	✔️	✔️
libericaopenjdk-8		✔️	✔️	✔️		✔️	✔️	✔️
libericaopenjdk-8-alpine		✔️	✔️	✔️	✔️	✔️	✔️
libericaopenjdk-8-debian		✔️	✔️	✔️	✔️	✔️
libericaopenjdk-11		✔️	✔️	✔️		✔️	✔️	✔️
libericaopenjdk-11-alpine		✔️	✔️	✔️	✔️	✔️	✔️
libericaopenjdk-11-debian		✔️	✔️	✔️	✔️	✔️
libericaopenjdk-17		✔️	✔️	✔️		✔️	✔️	✔️
libericaopenjdk-17-alpine		✔️	✔️	✔️	✔️	✔️	✔️
libericaopenjdk-17-debian		✔️	✔️	✔️	✔️	✔️
microsoft-openjdk-11-ubuntu	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
microsoft-openjdk-17-ubuntu	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
microsoft-openjdk-21-ubuntu	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
oracle-graalvm-17		✔️	✔️	✔️		✔️		✔️
oracle-graalvm-21		✔️	✔️	✔️		✔️		✔️
sapmachine-11	✔️	✔️	✔️	✔️	✔️	✔️	✔️
sapmachine-17	✔️	✔️	✔️	✔️	✔️	✔️	✔️
sapmachine-21	✔️	✔️	✔️	✔️	✔️	✔️	✔️

Image Verification

Images under csanchez/maven and ghcr.io/carlossg/maven are signed with sigstore/cosign using GitHub OIDC

Verification can be done with cosign verify

Example:

COSIGN_EXPERIMENTAL=true cosign verify csanchez/maven:3-eclipse-temurin-17

Building

Build with the usual

docker build -t maven .

Tests are written using bats for Linux images and pester for Windows images (requires Pester 4.x) under the tests dir.

Use the env var TAG to choose what image to run tests against.

Linux

TAG=eclipse-temurin-17 bats tests

Windows

$env:TAG="openjdk-11" ; Invoke-Pester -Path tests

or run all the tests with

Linux

for dir in $(/bin/ls -1 -d */ | grep -v 'tests\|windows'); do TAG=$(basename $dir) bats tests; done

Windows

Get-ChildItem -File -Include "*windows*" | ForEach-Object { Push-Location ; $env:TAG=$_.Name ; Invoke-Pester -Path tests ; Pop-Location }

Bats can be easily installed with brew install bats-core on OS X.

Note that you may first need to:

git submodule init
git submodule update

Pester comes with most modern Windows (Windows 10 and Windows Server 2019), but is an older version than required. You may need to follow this tutorial on upgrading Pester to 4.x.

Adding New Images

• Copy an existing dir (other than eclipse-temurin-11) to the new name and update Dockerfile as needed.
• Update README.md to include the new image and table with packages installed in that image.
• When adding a new JDK then it also needs to be added to the beginning of common.sh
• Run github-action-generation.sh to generate new GitHub Actions for the new image
• When a parent image changes the latest tag to a new JDK version it can be updated in common.sh

Updating Maven version

• Search and replace all references to the previous version by the new version.
• Update environment variable SHA in eclipse-temurin-11/Dockerfile with value found in maven download page for the binary tar.gz archive.
• Update environment variable SHA in *-{nanoserver,windowsservercore}/Dockerfile with value found in maven download page for the binary zip archive.

Publishing to Docker Hub

In order to publish the images a PR needs to be opened against docker-library/official-images

For that we use publish.sh that runs generate-stackbrew-library.sh

License

View license information for the software contained in this image.

User Feedback

Issues

If you have any problems with or questions about this image, please contact us through a GitHub issue.

You can also reach many of the official image maintainers via the #docker-library IRC channel on Freenode.

Contributing

You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can.

Before you start to code, we recommend discussing your plans through a GitHub issue, especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing.

docker-maven's Issues

Building local Docker image(s) section in README.md

I added a small section in PR #39 that shows how to create custom/local Docker images.
Prior to this addition, the README.md focused exclusively on how to run the pre-made image.

Support building RPMs (for CentOS)

To support the below pom.xml dependency, I submitted PR #37

                <groupId>org.codehaus.mojo</groupId>
                <artifactId>rpm-maven-plugin</artifactId>

Dynamically choosing the Apache mirror and GPG verification of the Maven binary

Recently I've managed to write a shell script doing these two things for another project. The code is here: https://github.com/zloster/FrameworkBenchmarks/blob/master/toolset/setup/linux/systools/maven.sh
IMO it seems as nice update for the docker script to have this two things:

1. Those who build the images themselves will benefit from the preferred Apache mirror
2. The script will no more need the SHA sum to be maintained

/root/.m2 should not be a volume

The Dockerfile documentation specifies that If any build steps change the data within the volume after it has been declared, those changes will be discarded.

By declaring /root/.m2/ as a volume it is no longer possible to extend the maven dockerfile and do mvn install during build as all the installed packages will be discarded unless you specify a different local maven repository.

If you choose to keep the volume declaration for some reason, then at least make it clear in the documentation that a user extending the image should use a different local maven repository.

Include the specific jdk version as part of the image (and its tags)

It would be really nice to be able to address the specific version of the JDK available with the maven docker image, e.g. maven:3.5.0-8u141

Fixing a specific openjdk version in the docker image gives the advantage of having reproducible builds based on the maven docker image, because with this we can guarantee that code compiled with a specific combination of maven and openjdk version will produce the exact same results which is not the case if we let the tag open as it is today, e.g. a user can download the docker image in different moments and get different versions of the openjdk so he won't be able to reproduce the builds because different versions of the compiler can generate different bytecode.

Of course the bad part is that this implies a little bit of extra maintenance because we will need to update the version of the JDK when a new version is released, however this is really not frequent and in any case most of the users wouldn’t even notice that they are not using the latest in case that this takes some time :) but in revenge we win a really valuable use case for this docker image.

Surefire fork fails on 3.5.3

Our builds configured in Bitbucket Pipelines using the latest release 3.5.3 are all failing all of a sudden with the following stacktrace:

[ERROR] The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /opt/atlassian/pipelines/agent/build && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -jar /opt/atlassian/pipelines/agent/build/target/surefire/surefirebooter1173070707154269215.jar /opt/atlassian/pipelines/agent/build/target/surefire 2018-03-28T12-44-59_326-jvmRun1 surefire1185691907430284876tmp surefire_0554936172727229418tmp
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /opt/atlassian/pipelines/agent/build && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -jar /opt/atlassian/pipelines/agent/build/target/surefire/surefirebooter1173070707154269215.jar /opt/atlassian/pipelines/agent/build/target/surefire 2018-03-28T12-44-59_326-jvmRun1 surefire1185691907430284876tmp surefire_0554936172727229418tmp
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:686)
[ERROR] 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:535)
[ERROR] 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:280)
[ERROR] 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
[ERROR] 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124)
[ERROR] 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
[ERROR] 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
[ERROR] 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] 	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
[ERROR] 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
[ERROR] 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
[ERROR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] 	at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[ERROR] -> [Help 1]

When we use the fixed version 3.5.2 instead of latest the builds succeed.

maven is not able to download anything from central because ssl don't work

In my experience, you have to add :

RUN apt-get install -y ca-certificates-java && update-ca-certificates -f

to have ssl working out of the box.

Artifact caching for Multi-stage Builds

I would love to use this for a multi-stage build, but the lack of a volume mount option for docker build poses a serious inefficiency due to the lack of artifact caching.

Are you aware of any good alternatives?

Running container return "no such file or directory"

I try to run this line on archlinux:

docker run maven:latest mvn

i get this error:

standard_init_linux.go:195: exec user process caused "no such file or directory"

i have update to the latest container with docker pull maven:latest

with docker version Docker version 17.12.0-ce, build 486a48d270

Maven Surefire >= 2.20 breaks on alpine/slim

Per this issue, the surefire plugin breaks when ps is missing or doesn't support the -p flag. On alpine, -p isn't supported, and on slim ps is missing altogether. Since surefire is so ubiquitous, would it make sense to add the procps package to these docker images to support it?

Issues pulling images after last update (3.5.2)

After the latest update, there are issues pulling the images. I thought it might be a cache thing but it looks like it's not getting fixed (been a couple of hours I've been trying).

$ docker pull maven:3.5-jdk-8-alpine
3.5-jdk-8-alpine: Pulling from library/maven
no matching manifest for linux/amd64 in the manifest list entries

Is there something that needs to be configured manually? It looks like this image just migrated to the Docker Store so I was wondering if that's related somehow. Note that I can pull images before the update today (e.g. 3.5.0 still works).

Docker maven images alpine velocity issue

Alpine version of docker maven (3.5.2-jdk-8-alpine) does'nt allow to use openclover to run a code analysis.
Running maven clean install using clover maven plugin results in a NullPointerException trying to reach a velocity template (.vm file)

This issue is not reproducible using the regular version of maven image (3.5.2-jdk-8)

Test Case

you can reproduce this issue using a little project with this plugin

<plugin>
    <groupId>org.openclover</groupId>
    <artifactId>clover-maven-plugin</artifactId>
    <version>4.2.1</version>
    <configuration>
         <generateJson>true</generateJson>
    </configuration>
    <executions>
        <execution>
            <id>clover</id>
            <phase>verify</phase>
            <goals>
                <goal>setup</goal>
                <goal>check</goal>
                <goal>aggregate</goal>
                <goal>clover</goal>
            </goals>
        </execution>
    </executions>
</plugin>

zookeeper maven dependency bug

I'm continuously getting this bug whenever i try to run the zookeeper client code i get an error .
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/zookeeper/KeeperException

any help would be appreciated .

base url response 404

BASE_URL=https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/${MAVEN_VERSION}
the url response statuscode 404

Using private repositories

Hi I want to just build my java project with this image. The problem is, that I have a private repository to download artifacts from. Is it somehow possible to configure the image to add private repositories?

Add "Packaging a local repository with the image" paragraph to dockerhub [Feature Request]

There is no comments about /root/.m2 folder being a volume right now in dockerhub page. It can be extremely frustrating to debug.

Switch to Alpine Linux

Are there any plans for introducing Alpine Linux builds? Locally, by just switching from openjdk-8-jdk to openjdk-8-jdk-alpine (had to add curl and tar installation) it reduced image size from over 600MB to just 150 MB:

$ docker images
REPOSITORY          TAG                    IMAGE ID            CREATED             SIZE
<none>              <none>                 bf36783f4f83        6 seconds ago       156.8 MB
maven               3.3.9-jdk-8            a42124be49e0        2 weeks ago         652.8 MB

Update to Maven 3.5.2

Maven 3.5.2 was released some days ago so maybe a good idea to update the version.

Git not available in the image

Hi,
Why don't include some SCM (like Git) in the VM to be able to perform a release process ?

Thanks

[DISCUSSION] Support for JDKs other than OpenJDK.

I'm completely open to the answer here being no, but I simply wanted to ask the question if there might be appetite for official maven docker images built on top of more than just the open JDK. Maybe the Oracle JDK and the IBM JDK. We in Apache Commons regularly test our distributions on those and were thinking about including them in our Travis-CI builds.

Thoughts?

Rebuild images to include java 1.8.0_131 (Improvements for Docker)

All the your 1.8 images uses 1.8.0_121.

Pre downloaded and cached dependencies, but it still download dependencies when package.

Is the above screenshot right?

Call mvn archetype:generate on maven:3.5.2-jdk-9 does not work

The same works for 3.5.2-jdk-8.

$ docker run -ti --rm maven:3.5.2-jdk-9 mvn archetype:generate
[INFO] Scanning for projects...
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-clean-plugin:2.5: Plugin org.apache.maven.plugins:maven-clean-pl
ugin:2.5 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-clean-plugin:jar:
2.5
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.4/maven-install-plugin-2.4.pom
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-install-plugin:2.4: Plugin org.apache.maven.plugins:maven-instal
l-plugin:2.4 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-install-plugi
n:jar:2.4Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/2.7/maven-deploy-plugin-2.7.pom
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-deploy-plugin:2.7: Plugin org.apache.maven.plugins:maven-deploy-plugin:2.7 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-deploy-plugin:j
ar:2.7Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-site-plugin/3.3/maven-site-plugin-3.3.pom
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-site-plugin:3.3: Plugin org.apache.maven.plugins:maven-site-plugin:3.3 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-site-plugin:jar:3.3
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-antrun-plugin:1.3: Plugin org.apache.maven.plugins:maven-antrun-
plugin:1.3 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-antrun-plugin:j
ar:1.3
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-5/maven-assembly-plugin-2.2
-beta-5.pom
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5: Plugin org.apache.maven.plugins:mave
n-assembly-plugin:2.2-beta-5 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:mav
en-assembly-plugin:jar:2.2-beta-5
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/2.8/maven-dependency-plugin-2.8.po
m
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-dependency-plugin:2.8: Plugin org.apache.maven.plugins:maven-dep
endency-plugin:2.8 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-depende
ncy-plugin:jar:2.8
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-release-plugin/2.3.2/maven-release-plugin-2.3.2.pom
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-release-plugin:2.3.2: Plugin org.apache.maven.plugins:maven-release-plugin:2.3.2 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-release-p
lugin:jar:2.3.2
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml
Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml
[WARNING] Could not transfer metadata org.apache.maven.plugins/maven-metadata.xml from/to central (https://repo.maven.apache.org/maven2): java.lan
g.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
[WARNING] Could not transfer metadata org.codehaus.mojo/maven-metadata.xml from/to central (https://repo.maven.apache.org/maven2): java.lang.Runti
meException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
[WARNING] Failure to transfer org.apache.maven.plugins/maven-metadata.xml from https://repo.maven.apache.org/maven2 was cached in the local reposi
tory, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer metadata org.apache.maven.plugins/maven-metadata.xml from/to central (https://repo.maven.apache.org/maven2): java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
[WARNING] Failure to transfer org.codehaus.mojo/maven-metadata.xml from https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer metadata org.codehaus.mojo/maven-metadata.xml from/to central (https://repo.maven.apache.org/maven2): java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.815 s
[INFO] Finished at: 2018-02-13T12:33:14Z
[INFO] Final Memory: 9M/30M
[INFO] ------------------------------------------------------------------------
[ERROR] No plugin found for prefix 'archetype' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/root/.m2/repository), central (https://repo.maven.apache.org/maven2)] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundForPrefixException
[node1] (local) [email protected] ~

Documentation still talks about onbuild, despite removal

Seriously confusing. I don't like the onbuild now I understand more about it, and very much understand the decision to remove, but could you please clean up the documentation? I'm not yet familiar enough with docker and dockerhub to know how to do a pull-request for this.

SVN Error (E235000) when running "mvn release:prepare"

I get the following error when running mvn release:prepare...

[ERROR] svn: E235000: In file '/build/subversion-Hohtq2/subversion-1.8.10/subversion/libsvn_client/copy.c' line 1386: assertion failed (commit_items != NULL)

Could this be a error with the particular version of SVN included in the image?

Not authorized, ReasonPhrase:Unauthorized - custom settings.xml

Hi,

I've configured the server section of a custom settings.xml file to include the username/password and have copied it to create a custom image. Here is the content of my Dockerfile

FROM maven:3.5.0-jdk-8-alpine
COPY settings.xml /usr/share/maven/ref/

With the same credentials in the settings.xml I'm able to login to nexus as well as resolve dependencies (if I directly run mvn dependency:resolve on my MacBook), but it is throwing 401 while running from docker. Below is the error:

[ERROR] Failed to execute goal on project my-app: Could not resolve dependencies for project com.home.myapp:my-app:jar:0.0.1-SNAPSHOT: Failed to collect dependencies at com.home.pages:content-core:jar:0.0.28: Failed to read artifact descriptor for com.home.pages:content-core:jar:0.0.28: Could not transfer artifact com.home.pages:content-core:jar:0.0.28 from/to release-repo (http://my-private-repo.com/repositories/releases/): Not authorized , ReasonPhrase:Unauthorized. -> [Help 1]

Please help.

Local settings.xml not picked up by Jenkins agent

I'm using this image to build on jenkins:

  agent {
    docker {
      image 'maven:3-jdk-8-alpine'
      args '-v ${HOME}/.m2:/root/.m2'
    }
  }

The ${HOME}/.m2/settings.xml is there but is not getting picked up.

Using help:effective-settings, I get this:

Effective user-specific configuration settings:

<?xml version="1.0" encoding="UTF-8"?>
<!-- ====================================================================== -->
<!--                                                                        -->
<!-- Generated by Maven Help Plugin on 2018-01-10T09:13:42                  -->
<!-- See: http://maven.apache.org/plugins/maven-help-plugin/                -->
<!--                                                                        -->
<!-- ====================================================================== -->

<!-- ====================================================================== -->
<!--                                                                        -->
<!-- Effective Settings for '?' on '0c8a16058336'                           -->
<!--                                                                        -->
<!-- ====================================================================== -->

<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd">
  <localRepository xmlns="http://maven.apache.org/SETTINGS/1.1.0">/var/lib/jenkins/workspace/yah_master-W74OVL5IJZCMBOCWHOODNNWVE45JYUK5JBJSNCYBJ4O3HKTTZMQQ/?/.m2/repository</localRepository>
  <pluginGroups xmlns="http://maven.apache.org/SETTINGS/1.1.0">
    <pluginGroup>org.apache.maven.plugins</pluginGroup>
    <pluginGroup>org.codehaus.mojo</pluginGroup>
  </pluginGroups>
</settings>

I have also tried adding the settings.xml to /usr/share/maven/ref but get the same settings:

  agent {
    docker {
      image 'maven:3-jdk-8-alpine'
      args '-v ${HOME}/.m2/settings.xml:/usr/share/maven/ref/settings.xml -v ${HOME}/.m2:/root/.m2'
    }
  }

Is there a way to force the maven image to use ${HOME}/.m2/settings.xml?

Mavan:3.5-JDK-8 uses incorrect version of Maven

When you down load docker image maven:3.5-jdk-8 and run the following commend, the maven version is not 3.5.0, but 3.5.2. Using the above docker container, I would expect version 3.5.0.

3.5-jdk-8-alpine: no longer able to build java code

I use maven:3.5-jdk-8-alpine as the base container for a container that builds java code using maven. The maven build now fails with the error:

No compiler is provided in this environment.  Perhaps you are running on a JRE rather than a JDK?

Looking at the 3.5-jdk-8-alpine Dockerfile, I see this message appears to be true as the maven Dockerfile now says:

FROM openjdk:8u121-jre-alpine

This was changed from using "jdk" instead of "jre" with commit b7f10a8, as illustrated here: b7f10a8#diff-fbac60dc291168cfb53991ab429c34fc. This was to address issue #46.

I'm assuming the main motivation for the maven images is to build Java code, so a jdk version is needed. It appears that the simple fix would be to use openjdk:8u121-jdk-alpine

Permission denied running openjdk:8-jdk-alpine

Using this Dockerfile :
https://github.com/carlossg/docker-maven/blob/322d0dff5d0531ccaf47bf49338cb3e294fd66c8/jdk-8/Dockerfile

FROM openjdk:8-jdk-alpine

RUN apk add --no-cache curl tar bash

ARG MAVEN_VERSION=3.3.9
ARG USER_HOME_DIR="/root"

RUN mkdir -p /usr/share/maven /usr/share/maven/ref \
  && curl -fsSL http://apache.osuosl.org/maven/maven-3/$MAVEN_VERSION/binaries/apache-maven-$MAVEN_VERSION-bin.tar.gz \
    | tar -xzC /usr/share/maven --strip-components=1 \
  && ln -s /usr/share/maven/bin/mvn /usr/bin/mvn

ENV MAVEN_HOME /usr/share/maven
ENV MAVEN_CONFIG "$USER_HOME_DIR/.m2"

COPY mvn-entrypoint.sh /usr/local/bin/mvn-entrypoint.sh
COPY settings-docker.xml /usr/share/maven/ref/

VOLUME "$USER_HOME_DIR/.m2"

ENTRYPOINT ["/usr/local/bin/mvn-entrypoint.sh"]
CMD ["mvn"]

Gives the following output

sudo docker run maven-docker
docker: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused "exec: \"/usr/local/bin/mvn-entrypoint.sh\": permission denied"\n".

Any ideas how to fix?

Can't find my .jar file after running mvn clean install in my image

Hello. I am new to JAVA and Docker so please spare me. I also asked for help on StackOverflow but did not get any help. Essentially, I have two Java projects:

• project-cms
• project-app

I am using maven:3.5.2-jdk-8-alpine to build an image from project-cms and then trying to build an image of project-app using the image created from project-cms. project-app has a dependency on a .jar file that project-cms generates when I run mvn clean install. However, my Docker image for project-app does not build because it cannot find the .jar file within the image created from project-cms. This is how my two Docker files look:

project-cms/Dockerfile

FROM maven:3.5.2-jdk-8-alpine
LABEL Name=project-cms Version=1.0.0 

# Container configuration
RUN mkdir /project-cms
COPY . /project-cms
WORKDIR /project-cms
VOLUME /project-cms
RUN mvn clean install

project-app/Dockerfile

FROM project-cms:latest
LABEL Name=project-app Version=1.0.0 

# Container configuration
RUN mkdir /app
COPY . /app
WORKDIR /app
VOLUME /app
RUN mvn clean install && mvn build
EXPOSE 8080
CMD [ "mvn", "tomcat7:run" ]

When I run docker image ls after building the project-cms/Dockerfile, everything looks good and so I try to build project-app/Dockerfile. This is where it breaks in the RUN step. My understanding is that the required .jar file is not available in the project-cms image's .m2 folder. To check this, I ran docker run -it project-cms sh and looked into the .m2 folder and all I could find were two files:

• copy_reference_file.log
• settings-docker.xml

I am not sure where any of the dozens of dependencies listed in my .pom file are. Can someone please help me resolve this?

Cache m2 dependencies for subsequent builds

Hi,

Thanks for this great docker image !
Is it possible to cache already downloaded m2 dependencies so that next time build happens, it doesn't download once again all dependencies ?
Thanks

3.3.9 Containers fail to run with non-root user

When specifying a non-root user you get an error:

$ docker run -u 1000 -ti index.docker.io/maven:3.3.9-jdk-8 bash touch: cannot touch ‘/root/.m2/copy_reference_file.log’: Permission denied Can not write to /root/.m2/copy_reference_file.log. Wrong volume permissions?

In the main README it gives example about running as a non-root user but now fails with the addition/fix of issue #11 [https://github.com/carlossg/docker-maven/commit/363ef271b86142d151f742fefa46d9d13bb656e6].

In the meantime I went back to maven:3.3.3 containers as it doesn't have this fix yet.

Thanks,

Art

Add Maven docker image for windows based on the OpenJDK for windows images

I think it is a good idea to add the windows based maven images by extending the recently released openjdk docker images for windows:

https://github.com/docker-library/openjdk/blob/bd3c2a9867c9dc6a9a8425a8df5c54edf0cbf2cc/6-jdk/Dockerfile
https://github.com/docker-library/openjdk/blob/9745c87a15896ec558429a826e23926e721e4846/8-jdk/windows/windowsservercore/Dockerfile

Problem using mvn at building time

I have the following use case:
1 - In the Dockerfile I build a mvn project and generate some jars
2 - then I go and build another project which uses the previous jars as dependencies

with the /root/.m2 volume, I find that the dependency jars (build on step 1), are gone, so I cannot successfully build the second project. This is maybe because the Dockerfile has layers, and the repository is not persisted in the second layer?

I already tried the approach that you advise in the README (using the settings.xml, as persisted repository), but I think this approach is designed to persist the repositories after the build of the Dockerfile , on runtime. I can see this image is designed to use maven on runtime, but what would be the correct way to use it also during building time?

maven:3-jdk-9 images have broken ssl certs

It seems like maven can't download any dependencies in this image. Run this: docker run -it maven:3-jdk-9 mvn dependency:tree

Expected output:

lots of this kinda thing:

Downloaded: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/16/maven-plugins-16.pom (13 kB at 392 kB/s)

followed by

[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.070 s
[INFO] Finished at: 2017-09-21T12:00:55Z
[INFO] Final Memory: 12M/40M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.8:tree (default-cli): Goal requires a project to execute but there is no POM in this directory (/). Please verify you invoked Maven from the correct directory. -> [Help 1]

Actual output:

lots of this

[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-site-plugin:3.3: Plugin org.apache.maven.plugins:maven-site-plugin:3.3 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-site-plugin:jar:3.3
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom

followed by

[WARNING] Failure to transfer org.codehaus.mojo/maven-metadata.xml from https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer metadata org.codehaus.mojo/maven-metadata.xml from/to central (https://repo.maven.apache.org/maven2): java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

then

[ERROR] No plugin found for prefix 'dependency' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/root/.m2/repository), central (https://repo.maven.apache.org/maven2)] -> [Help 1]

The message Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty leads me to suspect a cacerts issue but I don't know a fix.

This does not affect the -slim version of the image.

Consider adding a Dockerfile that doesn't declare the .m2 directory as a volume

Child images are unable to remove the VOLUME declaration for this directory, and this means that pre-cached maven artifacts need to be copied into this directory at container start time.

When many artifacts are cached, this can take a long time, and it's on the critical path of performing a maven build with this container. It would be nice to be able to just pre-download artifacts directly into the .m2/repository directory.

Volumes not mounted when container is launched from "dockerized" jenkins

Volumes mentionned in my dockerfile are mounted when I launch "docker run -v src:src" (with related VOLUME arguments into my dockerfile) from my host, but not mounted (those from my jenkins workdir of course) when the same command is launched from a dockerized jenkins (I launch my run command using the "add build step" jenkins feature).

I tried to mount my jenkins "$WORKDIR/src" folder with no success so I added my java sources "manually" with ADD. This works fine but as i don't have any mounted volume, I can't bring back my built artifacts (war files) in my jenkins workdir.

I can't send them too to another network shared drive cause ssh not working.

maven:3.3 no longer useable, as-is, in docker.inside from jenkins docker pipeline

Sample Code:

timestamps { -> node('build && docker') {
    stage 'MAVEN 3.2 (win)'
        getDockerImage('maven:3.2').inside {
            sh 'mvn -v'
        }

    stage 'MAVEN 3.3 (fail)'
        getDockerImage('maven:3.3').inside {
            sh 'mvn -v'
        }
}}

def getDockerImage(imageName) {
    return { ->
        def img = docker.image(imageName)
        /* make sure we have the up-to-date image */
        img.pull()
        /* dance around https://issues.jenkins-ci.org/browse/JENKINS-34276 */
        return docker.image(img.imageName())
    }()
}

The 3.2 stage runs just fine but the 3.3 stage fails with:

[Pipeline] stage (MAVEN 3.3 (fail))
17:23:27 Entering stage MAVEN 3.3 (fail)
17:23:27 Proceeding
[Pipeline] sh
17:23:27 [maven-3-point-3] Running shell script
17:23:27 + docker pull maven:3.3
17:23:29 3.3: Pulling from library/maven
17:23:29 Digest: sha256:f6becf58234086fa8cbfa89a38917ed3bec81baaac4465c3275d51ec22b60461
17:23:29 Status: Downloaded newer image for maven:3.3
[Pipeline] sh
17:23:29 [maven-3-point-3] Running shell script
17:23:30 + docker inspect -f . maven:3.3
17:23:30 .
[Pipeline] withDockerContainer
17:23:30 $ docker run -t -d -u 1000:1000 -w /var/lib/jenkins/workspace/JCHRISTEN/maven-3-point-3 -v /var/lib/jenkins/workspace/JCHRISTEN/maven-3-point-3:/var/lib/jenkins/workspace/JCHRISTEN/maven-3-point-3:rw -v /var/lib/jenkins/workspace/JCHRISTEN/maven-3-point-3@tmp:/var/lib/jenkins/workspace/JCHRISTEN/maven-3-point-3@tmp:rw -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** maven:3.3 cat
[Pipeline] {
[Pipeline] sh
17:23:31 [maven-3-point-3] Running shell script
17:23:31 Error response from daemon: Container c744a6e4b7ecfc61ceb9d9c88c9af070309ea44d47e38f5b4ece06ecce6fdb17 is not running
[Pipeline] }
17:23:49 $ docker stop c744a6e4b7ecfc61ceb9d9c88c9af070309ea44d47e38f5b4ece06ecce6fdb17
17:23:49 $ docker rm -f c744a6e4b7ecfc61ceb9d9c88c9af070309ea44d47e38f5b4ece06ecce6fdb17
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // timestamps
[Pipeline] End of Pipeline
ERROR: script returned exit code -2
Finished: FAILURE

This used to work. In my opinion this kind of breakage is unacceptable and is the direct result of this image being far too opinionated (doing too much at startup).

This problem was originally identified in #14 which seems to have been summarily dismissed. Please reconsider.

How to avoid download of jar deps at every image building

Every time the code of java classes in my maven project changes, building an image requires to download again all the java dependencies from maven repositories.

I am trying to avoid that using a data volume, specifically I run docker run -v "$(pwd)":/root/.m2 but of course this command is not about building an image, so it does not help.

Docker does not support data volumes when you build an image.

Is there any other way you suggest to speed up the image building process avoiding the download of all the java dependencies?

Not usable under non-root user

Due to ARG USER_HOME_DIR="/root" it's not possible to start any processes under a different user.

$ docker run -it --rm -u $(id -u):$(id -g) maven bash
touch: cannot touch ‘/root/.m2/copy_reference_file.log’: Permission denied
Can not write to /root/.m2/copy_reference_file.log. Wrong volume permissions?

supprot arm64 architecture

I make maven image from arm64v8/openjdk:9-jdk to support arm64 and it build successed, so I want to konw maven can supprot arm64 architecture? if it can be support arm64 architecture we can add to update.

Issue with 3.5.0-jdk-8-alphine

When using maven:3.5.0-jdk-8-alphine
and running mvn install, I get the below error.
java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/libfontmanager.so

On researching this error is a result of using FROM openjdk:8-jre-alpine which has the issue. Alphine has not fixed this issue yet. The work around suggested is to use FROM openjdk:8u121-jre-alpine.
Can the maven container be updated to use this version of openjdk alphine until the issue is fixed? or better yet, can a minor version be specified which can then be used to get the specific jdk version when building the maven image?

Update to openjdk 8u151 on alpine

OpenJDK 8u151 has now been released. The maven project can be updated to the latest java version available on alpine.

jdk-8-alpine variant build from JRE image

You can imagine the inconvenience when JDK is not available on Maven image.

docker-maven/jdk-8-alpine/Dockerfile

Line 2 in 93d297e

FROM openjdk:8u121-jre-alpine

Using docker-maven in Drone CI

I' trying to use docker-maven as part of a Drone CI implementation. I have extended the docker-maven Dockerfile with mine, adding custom settings.xml:

My Dockerfile:

FROM maven:3-jdk-8

COPY settings.xml /usr/share/maven/ref/

My settings.xml:

<settings>
    <localRepository>/usr/share/maven/ref/repository</localRepository>
    <servers>
    <server>
        <id>${env.NEXUS_ID}</id>
        <username>${env.NEXUS_USERNAME}</username>
        <password>${env.NEXUS_PASSWORD}</password>
    </server>
    </servers>
    <pluginGroups>
        <pluginGroup>org.sonarsource.scanner.maven</pluginGroup>
    </pluginGroups>
    <profiles>
        <profile>
            <id>sonar</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <sonar.host.url>${env.SONAR_URL}</sonar.host.url>
            </properties>
        </profile>
     </profiles>
</settings>

The drone build is configured to use this custom image. I use docker environment variables to parameterize the maven settings. When the drone build starts, the first thing I do is check that the environment variables are right and the settings.xml file has been copied to the /usr/share/maven/ref/ folder. Everything seems ok.

Nevertheless, the build fails to execute an mvn clean deploy as it cannot deploy the resulting jar to my private nexus server.

When I execute the build manually in my local system with the same settings.xml and the same environment variables everything works fine. I have run out of ideas on how to determine if the problem is with the image or with other component. Any ideas?

Thanks for the great image and for your support!

'root' owns target directory.

When I compile my code using this container, the 'root' user owns the directory and the files inside. Can I change the user to something else?

Consider introducing a fourth coordinate in image versioning scheme

#53 highlights the potential for wide spread disaster if something is broken in an important, fundamental base image such as this.

I would humbly suggest that a fourth coordinate be introduced into the image version scheme.
The idea would be to:

• enable bug fixes and updates
• BUT without the danger of breaking downstream users (as long as they are using specific image versions).

My current idea would be to append a -[number] to the current existing version tags. This would maintain the maven version tracking, and allow a user to specify a (then immutable) image to base their system on.

For example (image versions numbers choose randomly for illustration):

• maven:3-jdk-8-alpine has a maven:3-10-jdk-8-alpine variant
• maven:3.5-jdk-8-alpine has a maven:3.5-99-jdk-8-alpine variant
• maven:3.5.2-jdk-8-alpine has a maven:3.5.2-66-jdk-8-alpine variant

For (example), maven:3-jdk-8-alpine may then be updated as needed.

maven:3-10-jdk-8-alpine may NEVER be changed. Ever. Under no circumstances. The only way it "changes" is to create a new image : maven:3-11-jdk-8-alpine.

The main problem I can think of at this point is that management of all these versions streams might become a nightmare...

Dependency Projects

I have 2 repositories in bitbucket. Now when pipeline is configured for both the repositories i am able to build repo 1 successfully and repo 1 is the dependency project of repo 2 . When i am trying to build repo 2 it says Could not resolve dependencies for project repo 1 project.
Please find the below yml i have configured.
image: maven:3.3.9

pipelines:
default:
- step:
caches:
- maven
script: # Modify the commands below to build your repository.
- mvn -s settings.xml # e.g. with settings.xml in the root of the project
- mvn clean install package # -B batch mode makes Maven less verbose

Any suggestions how to resolve repo 1 dependency in repo 2

How can I replace the settings.xml file?

Thanks for providing these container definitions. I have an Artifactory server that I'd like to use. Can I add a settings.xml to the container?