Open fabian-froehlich opened 5 months ago
@fabian-froehlich I've run your steps and it appears to me that when you download maven
inside an Alpine container it downloads the Alpine build of OpenJDK21 rather than using Temurin. I would suggest that the best approach for you would be to switch to the official docker image (maven:3-eclipse-temurin-21-alpine
)
@gdams good to see, that there is also an image for that! Sadly the issue remains the same for the Java-21 part.
Java 17
$ mvn -v
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/share/maven
Java version: 17.0.10, vendor: Eclipse Adoptium, runtime: /opt/java/openjdk
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-169-generic", arch: "amd64", family: "unix"
Java 21
$ mvn -v
Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher
Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.classworlds.launcher.Launcher
dockerfile
FROM maven:3-eclipse-temurin-21-alpine
CMD ["bash"]
that's strange, I'm not able to reproduce this on aarch64 so I'll try on amd64:
/ # mvn -v
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/share/maven
Java version: 21.0.2, vendor: Eclipse Adoptium, runtime: /opt/java/openjdk
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.4.16-linuxkit", arch: "aarch64", family: "unix"
I'm also not able to reproduce this on an amd64 box:
/ # mvn -v
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/share/maven
Java version: 21.0.2, vendor: Eclipse Adoptium, runtime: /opt/java/openjdk
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-126-generic", arch: "amd64", family: "unix"
@fabian-froehlich I wonder if you're experiencing the same error observed in https://stackoverflow.com/questions/11118237/maven-error-could-not-find-or-load-main-class-org-codehaus-plexus-classworlds-l. Can you please check through the solutions here?
Unfortunately no hint changed anything. I figured out, that when I execute "mvn -v" from within the docker build phase RUN mvn -v
it works. But it does not in the final Image. Maybe CMD ["bash"]
is the problem?
Interestingly the debug mode of bash shows the error in ci/cd environment and local as well. This time even for the JDK-17 variant of the image:
$ echo $M2_HOME
$ echo $M2
$ echo $M3_HOME
$ echo $JAVA_HOME
/opt/java/openjdk
$ echo $PATH
/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ bash -x mvn -v
+ '[' -z '' ']'
+ '[' -f /usr/local/etc/mavenrc ']'
+ '[' -f /etc/mavenrc ']'
+ '[' -f /root/.mavenrc ']'
+ cygwin=false
+ mingw=false
+ case "`uname`" in
++ uname
+ PRG=mvn
+ '[' -h mvn ']'
++ pwd
+ saveddir=/project/path/image
++ dirname mvn
+ MAVEN_HOME=./..
++ cd ./..
++ pwd
+ MAVEN_HOME=/project/path/common
+ cd /project/path/image
+ false
+ false
+ '[' -z /opt/java/openjdk ']'
+ JAVACMD=/opt/java/openjdk/bin/java
+ '[' '!' -x /opt/java/openjdk/bin/java ']'
++ echo '/project/path/common/boot/plexus-classworlds-*.jar'
+ CLASSWORLDS_JAR='/project/path/common/boot/plexus-classworlds-*.jar'
+ CLASSWORLDS_LAUNCHER=org.codehaus.plexus.classworlds.launcher.Launcher
+ false
++ find_maven_basedir -v
+++ find_file_argument_basedir -v
++++ pwd
+++ basedir=/project/path/image
+++ found_file_switch=0
+++ for arg in "$@"
+++ '[' 0 -eq 1 ']'
+++ '[' -v = -f -o -v = --file ']'
+++ echo /project/path/image
++ basedir=/project/path/image
++ wdir=/project/path/image
++ '[' /project/path/image '!=' / ']'
++ '[' -d /project/path/image/.mvn ']'
+++ cd /project/path/image/..
+++ pwd
++ wdir=/project/path/common
++ '[' /project/path/common '!=' / ']'
++ '[' -d /project/path/common/.mvn ']'
+++ cd /project/path/common/..
+++ pwd
++ wdir=/builds/pvog
++ '[' /builds/pvog '!=' / ']'
++ '[' -d /project/path/.mvn ']'
+++ cd /project/path/..
+++ pwd
++ wdir=/builds
++ '[' /builds '!=' / ']'
++ '[' -d /builds/.mvn ']'
+++ cd /builds/..
+++ pwd
++ wdir=/
++ '[' / '!=' / ']'
++ echo /project/path/image
+ MAVEN_PROJECTBASEDIR=/project/path/image
++ concat_lines /project/path/image/.mvn/jvm.config
++ '[' -f /project/path/image/.mvn/jvm.config ']'
+ MAVEN_OPTS=' '
+ false
+ export MAVEN_PROJECTBASEDIR
+ MAVEN_CMD_LINE_ARGS='/root/.m2 -v'
+ export MAVEN_CMD_LINE_ARGS
+ exec /opt/java/openjdk/bin/java -classpath '/project/path/common/boot/plexus-classworlds-*.jar' -Dclassworlds.conf=/project/path/common/bin/m2.conf -Dmaven.home=/project/path/common -Dlibrary.jansi.path=/project/path/common/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/project/path/image org.codehaus.plexus.classworlds.launcher.Launcher -v
Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher
Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.classworlds.launcher.Launcher
Unfortunately no hint changed anything. I figured out, that when I execute "mvn -v" from within the docker build phase
RUN mvn -v
it works. But it does not in the final Image. MaybeCMD ["bash"]
is the problem?Interestingly the debug mode of bash shows the error in ci/cd environment and local as well. This time even for the JDK-17 variant of the image:
$ echo $M2_HOME $ echo $M2 $ echo $M3_HOME $ echo $JAVA_HOME /opt/java/openjdk $ echo $PATH /opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin $ bash -x mvn -v + '[' -z '' ']' + '[' -f /usr/local/etc/mavenrc ']' + '[' -f /etc/mavenrc ']' + '[' -f /root/.mavenrc ']' + cygwin=false + mingw=false + case "`uname`" in ++ uname + PRG=mvn + '[' -h mvn ']' ++ pwd + saveddir=/project/path/image ++ dirname mvn + MAVEN_HOME=./.. ++ cd ./.. ++ pwd + MAVEN_HOME=/project/path/common + cd /project/path/image + false + false + '[' -z /opt/java/openjdk ']' + JAVACMD=/opt/java/openjdk/bin/java + '[' '!' -x /opt/java/openjdk/bin/java ']' ++ echo '/project/path/common/boot/plexus-classworlds-*.jar' + CLASSWORLDS_JAR='/project/path/common/boot/plexus-classworlds-*.jar' + CLASSWORLDS_LAUNCHER=org.codehaus.plexus.classworlds.launcher.Launcher + false ++ find_maven_basedir -v +++ find_file_argument_basedir -v ++++ pwd +++ basedir=/project/path/image +++ found_file_switch=0 +++ for arg in "$@" +++ '[' 0 -eq 1 ']' +++ '[' -v = -f -o -v = --file ']' +++ echo /project/path/image ++ basedir=/project/path/image ++ wdir=/project/path/image ++ '[' /project/path/image '!=' / ']' ++ '[' -d /project/path/image/.mvn ']' +++ cd /project/path/image/.. +++ pwd ++ wdir=/project/path/common ++ '[' /project/path/common '!=' / ']' ++ '[' -d /project/path/common/.mvn ']' +++ cd /project/path/common/.. +++ pwd ++ wdir=/builds/pvog ++ '[' /builds/pvog '!=' / ']' ++ '[' -d /project/path/.mvn ']' +++ cd /project/path/.. +++ pwd ++ wdir=/builds ++ '[' /builds '!=' / ']' ++ '[' -d /builds/.mvn ']' +++ cd /builds/.. +++ pwd ++ wdir=/ ++ '[' / '!=' / ']' ++ echo /project/path/image + MAVEN_PROJECTBASEDIR=/project/path/image ++ concat_lines /project/path/image/.mvn/jvm.config ++ '[' -f /project/path/image/.mvn/jvm.config ']' + MAVEN_OPTS=' ' + false + export MAVEN_PROJECTBASEDIR + MAVEN_CMD_LINE_ARGS='/root/.m2 -v' + export MAVEN_CMD_LINE_ARGS + exec /opt/java/openjdk/bin/java -classpath '/project/path/common/boot/plexus-classworlds-*.jar' -Dclassworlds.conf=/project/path/common/bin/m2.conf -Dmaven.home=/project/path/common -Dlibrary.jansi.path=/project/path/common/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/project/path/image org.codehaus.plexus.classworlds.launcher.Launcher -v Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.classworlds.launcher.Launcher
Ahh this makes sense, we removed bash from the alpine image to keep it lightweight. You'll need to manually install it or switch to using sh
as your CMD
You removed bash
only from the JDK-21 image, or from the JDK-17 image as well? Is it not strange, that bash -x mvn -v
does produce some output if there is no bash installed in the first place.
In the first post (at the time I was not using the special maven image) I was installing bash
with apk add
.
Applying this to maven:3-eclipse-temurin-21-alpine
did no change. Also using CMD ["sh"]
instead of bash had no impact on the error message.
Update:
I got the minimal example with maven:3-eclipse-temurin-21-alpine
working by selecting another gitlab-runner environment. The config behind and initial setup is not transparent to me. I will reach out to our internal it department. Maybe we find out the conflict in the configuration so I can report it here.
Edit: I am still asking myself, if I would need to execute the maven-entrypoint code somehow, as it seems to copy a few config files that might be necessary in order to get maven working properly.
So the problem is reproducible, but we have not found any difference that explains this behavior.
I can say that these images work
and this one is not
The patch version here also hides the fact that the newer image contains the minor version upgrade in alpine linux. We install bash in these images. Running a maven command inside the docker build process RUN mvn - v
is no problem.
It looks like the best idea would be to let this slide a bit and wait for the next patch versions of jdk + maven + alpine that might fix this problem.
Today we failed to start our spring-boot (3.2.3) application based on the latest image 21.0.2_13-jre-alpine
in our kubernetes cluster.
Downgrading to 21.0.1_12-jre-alpine
solved that issue.
FROM eclipse-temurin:21.0.2_13-jre-alpine as builder
WORKDIR /home/appuser
ARG JAR_FILE=target/application.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract
FROM eclipse-temurin:21.0.2_13-jre-alpine
RUN addgroup -g 1000 appuser && adduser -D -u 1000 -G appuser appuser
WORKDIR /home/appuser
EXPOSE 8080
COPY --from=builder /home/appuser/dependencies/ ./
COPY --from=builder /home/appuser/spring-boot-loader/ ./
COPY --from=builder /home/appuser/snapshot-dependencies/ ./
COPY --from=builder /home/appuser/application/ ./
USER appuser
CMD ["sh", "-c", "exec java org.springframework.boot.loader.launch.JarLauncher"]
Exception
Picked up JAVA_TOOL_OPTIONS: ...
at org.springframework.boot.loader.net.protocol.jar.JarUrlClassLoader.loadClass(JarUrlClassLoader.java:94)
at org.springframework.boot.loader.launch.LaunchedClassLoader.loadClass(LaunchedClassLoader.java:91)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
... 6 more
Exception in thread "main" java.lang.NoClassDefFoundError: org/springframework/boot/context/event/ApplicationStartedEvent
at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredMethods(Unknown Source)
at java.base/java.lang.Class.getDeclaredMethod(Unknown Source)
at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:89)
at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:53)
at org.springframework.boot.loader.launch.JarLauncher.main(JarLauncher.java:58)
Caused by: java.lang.ClassNotFoundException: org.springframework.boot.context.event.ApplicationStartedEvent
It looks like this problem is no longer Maven related and is a more general problem of interoperability between Java, Alpine and our host system.
Shall I create a new issue for that?
I think we can keep this open for the history.
Please add the exact image (with tag) that you are using
21.0.2_13-jdk-alpine
Please add the version of Docker you are running
25.0.2
What happened?
Switching from
21.0.1_12-jdk-alpine
to21.0.2_13-jdk-alpine
causes some problems withmaven
. The alpine JDK image is used as a base for building our builder image for gitlab ci/cd.The minimal example dockerfile looks like this:
Executing
mvn -v
results in this error:Building the dockerfile with the older version
21.0.1_12-jdk-alpine
as a base, the command gets executed wellBetween the two images there are a few changes under the hood:
In the course of putting all these details together, I discovered that the problem with Maven was also present if I just used the
alpine:3.19
image tag itself. It would be helpful for us if we could use the latest temurin jdk without the need to switch to the newest alpine image.Both container are running on
gitlab-runner 16.7.0
.A few odds to add:
alpine 3.19
andmaven 3.9.5
and hence brings a bundled Oracle OpenJDK 21 with it. And it works. So the root problem could be in Alpine 3.19, but the Temurin JDK 21 could also be interfering with Oracle JDK 21, resulting in the class problem.Relevant log output (21.0.2_13-jdk-alpine)
Relevant log output (21.0.1_12-jdk-alpine)