Can't run Maven 3.6.3 on JDK7

Asked 11/5, 2021 at 6:43 Answered 11/5, 2021 at 7:15

According to the Maven release history, it should be possible to run any recent version of Maven (at the time of writing anyway) on JDK 7. However, when I try to do so on my Ubuntu 21.04 machine, I get an error: java.lang.UnsupportedClassVersionError: com/google/inject/Module : Unsupported major.minor version 52.0.

It happens even while running mvn without any parameters in a directory that doesn't contain any Java files or pom.xml file.

Maven info:

└─❯ mvn -version
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: /home/jqno/.jabba/jdk/1.7.80-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.11.0-16-generic", arch: "amd64", family: "unix"

(I also have a Zulu 1.7.292 and an OpenJDK installed; the behavior there is the same.)

Full stack trace:

└─❯ mvn clean
---------------------------------------------------
constituent[0]: file:/usr/share/maven/conf/logging/
constituent[1]: file:/usr/share/maven/lib/commons-lang3.jar
constituent[2]: file:/usr/share/maven/lib/sisu-plexus.jar
constituent[3]: file:/usr/share/maven/lib/maven-core-3.x.jar
constituent[4]: file:/usr/share/maven/lib/maven-shared-utils.jar
constituent[5]: file:/usr/share/maven/lib/sisu-inject.jar
constituent[6]: file:/usr/share/maven/lib/jansi.jar
constituent[7]: file:/usr/share/maven/lib/plexus-component-annotations.jar
constituent[8]: file:/usr/share/maven/lib/plexus-interpolation.jar
constituent[9]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar
constituent[10]: file:/usr/share/maven/lib/aopalliance.jar
constituent[11]: file:/usr/share/maven/lib/wagon-provider-api.jar
constituent[12]: file:/usr/share/maven/lib/jsr250-api.jar
constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar
constituent[14]: file:/usr/share/maven/lib/plexus-cipher.jar
constituent[15]: file:/usr/share/maven/lib/maven-slf4j-provider-3.x.jar
constituent[16]: file:/usr/share/maven/lib/maven-resolver-transport-wagon.jar
constituent[17]: file:/usr/share/maven/lib/wagon-file.jar
constituent[18]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar
constituent[19]: file:/usr/share/maven/lib/maven-resolver-provider-3.x.jar
constituent[20]: file:/usr/share/maven/lib/jcl-over-slf4j.jar
constituent[21]: file:/usr/share/maven/lib/wagon-http-shaded.jar
constituent[22]: file:/usr/share/maven/lib/maven-compat-3.x.jar
constituent[23]: file:/usr/share/maven/lib/guice-no-aop.jar
constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar
constituent[25]: file:/usr/share/maven/lib/guava.jar
constituent[26]: file:/usr/share/maven/lib/maven-resolver-connector-basic.jar
constituent[27]: file:/usr/share/maven/lib/commons-cli.jar
constituent[28]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar
constituent[29]: file:/usr/share/maven/lib/maven-resolver-api.jar
constituent[30]: file:/usr/share/maven/lib/plexus-utils.jar
constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar
constituent[32]: file:/usr/share/maven/lib/maven-resolver-util.jar
constituent[33]: file:/usr/share/maven/lib/maven-resolver-impl.jar
constituent[34]: file:/usr/share/maven/lib/cdi-api.jar
constituent[35]: file:/usr/share/maven/lib/maven-resolver-spi.jar
constituent[36]: file:/usr/share/maven/lib/maven-embedder-3.x.jar
constituent[37]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar
constituent[38]: file:/usr/share/maven/lib/commons-io.jar
constituent[39]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar
constituent[40]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar
constituent[41]: file:/usr/share/maven/lib/maven-model-3.x.jar
constituent[42]: file:/usr/share/maven/lib/javax.inject.jar
---------------------------------------------------
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/google/inject/Module : Unsupported major.minor version 52.0
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:425)
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
    at org.apache.maven.cli.MavenCli.container(MavenCli.java:636)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:282)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)

It looks like somewhere, Maven tries to load a class that is compiled for JDK8, given that it complains about an unsupported class version of 52.0. But I don't can't find which class, or why Maven tries to load it in the first place. Everything I can find on Google seems unrelated.

What's going on? How do I fix this?

UPDATE I've unzipped the /usr/share/maven/lib/guice-no-aop.jar file and run javap -verbose com.google.inject.Module, and it indeed has version 52.0. I don't know how that file got there (I would assume it was installed by apt install maven but I'm not sure).

Laban answered 11/5, 2021 at 6:43 Comment(14)

It's likely that you gave your JDK (not maven) a library that was compiled for versions 8+ of Java. So maven is working, but your compiler/runtime rejects one of your library classes. – Drayton 11/5, 2021 at 6:47

Is the output of mvn --version exactly as mentioned in your post because if I do that I got: Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) ? Can you please recheck that? – Sex 11/5, 2021 at 6:48

@Drayton I've updated the question: it happens even in an empty directory when I run mvn without any parameters, not even clean, so I don't know where the library should come from. – Laban 11/5, 2021 at 6:50

@Sex I just re-checked, but it is a direct copy/paste from my terminal. I don't see any hexadecimal number. – Laban 11/5, 2021 at 6:50

@Drayton I've updated the question again: the /usr/share/maven/lib/guice-no-aop.jar file was indeed compiled for JDK8. – Laban 11/5, 2021 at 6:54

@Laban I have that exact version of Maven. The only guice files I have are guice-4.2.1-no_aop.jar and guice.license. But the jar seems to have been built by 1.8.0_151-google-v7. However, mvn builds any project on my machine without that UnsupportedClassVersionError. Who removed the version from that jar in your installation? – Drayton 11/5, 2021 at 6:58

Just wondering: why? I understand that some people have legacy java 7 zombie application chained to some pillar down in the dungeon that they need to maintain ... but this rather looks like you are doing "active development" on Java7. If so ... why? – Communicative 11/5, 2021 at 6:58

@Drayton I don't know how the file got there, AFAIK I just did sudo apt install maven. I'll try to purge and re-install and see what happens. – Laban 11/5, 2021 at 7:11

@Communicative We need to disable parts of the legacy monolith as we're splitting functionality into microservices (which are built on more current versions of Java ;) ) – Laban 11/5, 2021 at 7:12

See my answer. The problem is the repackaged variant of Maven in Ubuntu...It's just fine to work in JDK 7 if you need to.. The problem also not related to dependencies...A reinstallation via package manager does not help here. You have to circumvent the usage of the Package manager... – Sex 11/5, 2021 at 7:16

@Sex Thanks, indeed that was it. I attempted a re-install but got the same faulty jars back. I wonder why Ubuntu would do such a thing, but there it is. Downloading from Apache directly solved the issue. – Laban 11/5, 2021 at 7:22

@jqno: I can take a guess at why this issue arose: Linux distribution packages (be they rpm or deb or anything else) have quite a different versioning/dependency concept than Java software. While in Java it is quite common to require different versions of the same library for different apps, in the Linux world there is a push towards "one version" of each package (with exceptions of course). Those models are not compatible so issues like this pop up again and again when using Java software packaged via Linux distros. – Philology 11/5, 2021 at 7:25

The approach to use one versions is simply wrong in Java world. The version concept in itself is not different. The distros trying to reduce all software on a system to the same dependency (versions) of things which does not work in Java world apart from becoming more problematic if JDK11, JDK11+ is becoming more popular. I forcast more issues like that in the future for Java based software in distros. – Sex 11/5, 2021 at 7:31

My opinion about Java software in distros is: Let the Java software use it's deps and do not try to repackage etc. also things like installing separate libs via package manager does not makes sense. Reinventing/Rewriting the dependencies via rpm/deb package dependencies... – Sex 11/5, 2021 at 7:32

The problem here is that Ubuntu has repackaged Maven which in result produces the issue.

As shown here if you check the version via:

mvn --version

Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: /home/jqno/.jabba/jdk/1.7.80-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.11.0-16-generic", arch: "amd64", family: "unix"

This shows that you are NOT using Apache Maven.

If you do that on plain command line and install Apache Maven via https://maven.apache.org/download.cgi you will get an output like this:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /Users/XXX/tools/maven
Java version: 1.7.0_302, vendor: Azul Systems, Inc., runtime: /Users/khmarbaise/.sdkman/candidates/java/7.0.302-zulu/zulu-7.jdk/Contents/Home/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"

The most important part is the first line:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)

This is Apache Maven.

Second if you take careful look into the error output:

constituent[0]: file:/usr/share/maven/conf/logging/
constituent[1]: file:/usr/share/maven/lib/commons-lang3.jar
constituent[2]: file:/usr/share/maven/lib/sisu-plexus.jar
constituent[3]: file:/usr/share/maven/lib/maven-core-3.x.jar
constituent[4]: file:/usr/share/maven/lib/maven-shared-utils.jar
constituent[5]: file:/usr/share/maven/lib/sisu-inject.jar
constituent[6]: file:/usr/share/maven/lib/jansi.jar
constituent[7]: file:/usr/share/maven/lib/plexus-component-annotations.jar
constituent[8]: file:/usr/share/maven/lib/plexus-interpolation.jar
constituent[9]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar
constituent[10]: file:/usr/share/maven/lib/aopalliance.jar
constituent[11]: file:/usr/share/maven/lib/wagon-provider-api.jar
constituent[12]: file:/usr/share/maven/lib/jsr250-api.jar
constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar
constituent[14]: file:/usr/share/maven/lib/plexus-cipher.jar
constituent[15]: file:/usr/share/maven/lib/maven-slf4j-provider-3.x.jar
constituent[16]: file:/usr/share/maven/lib/maven-resolver-transport-wagon.jar
constituent[17]: file:/usr/share/maven/lib/wagon-file.jar
constituent[18]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar
constituent[19]: file:/usr/share/maven/lib/maven-resolver-provider-3.x.jar
constituent[20]: file:/usr/share/maven/lib/jcl-over-slf4j.jar
constituent[21]: file:/usr/share/maven/lib/wagon-http-shaded.jar
constituent[22]: file:/usr/share/maven/lib/maven-compat-3.x.jar
constituent[23]: file:/usr/share/maven/lib/guice-no-aop.jar
constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar
constituent[25]: file:/usr/share/maven/lib/guava.jar
constituent[26]: file:/usr/share/maven/lib/maven-resolver-connector-basic.jar
constituent[27]: file:/usr/share/maven/lib/commons-cli.jar
constituent[28]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar
constituent[29]: file:/usr/share/maven/lib/maven-resolver-api.jar
constituent[30]: file:/usr/share/maven/lib/plexus-utils.jar
constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar
constituent[32]: file:/usr/share/maven/lib/maven-resolver-util.jar
constituent[33]: file:/usr/share/maven/lib/maven-resolver-impl.jar
constituent[34]: file:/usr/share/maven/lib/cdi-api.jar
constituent[35]: file:/usr/share/maven/lib/maven-resolver-spi.jar
constituent[36]: file:/usr/share/maven/lib/maven-embedder-3.x.jar
constituent[37]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar
constituent[38]: file:/usr/share/maven/lib/commons-io.jar
constituent[39]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar
constituent[40]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar
constituent[41]: file:/usr/share/maven/lib/maven-model-3.x.jar
constituent[42]: file:/usr/share/maven/lib/javax.inject.jar

Than you can see things like this:

constituent[3]: file:/usr/share/maven/lib/maven-core-3.x.jar
..
constituent[25]: file:/usr/share/maven/lib/guice-no-aop.jar

If you take a look into an original Apache Maven lib directory the files look like this:

javaee (master *)$ ls -la ~/tools/apache-maven-3.6.3/lib/
total 21000
drwxr-xr-x  65 khmarbaise  staff     2080 Nov  7  2019 .
drwxr-xr-x   9 khmarbaise  staff      288 Nov 21  2019 ..
-rw-r--r--   1 khmarbaise  staff    44908 Nov  7  2019 cdi-api-1.0.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 cdi-api.license
-rw-r--r--   1 khmarbaise  staff    53820 Nov  7  2019 commons-cli-1.4.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 commons-cli.license
-rw-r--r--   1 khmarbaise  staff   208700 Nov  7  2019 commons-io-2.5.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 commons-io.license
-rw-r--r--   1 khmarbaise  staff   501879 Nov  7  2019 commons-lang3-3.8.1.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 commons-lang3.license
drwxr-xr-x   3 khmarbaise  staff       96 Nov  7  2019 ext
-rw-r--r--   1 khmarbaise  staff  2591373 Nov  7  2019 guava-25.1-android.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 guava.license
-rw-r--r--   1 khmarbaise  staff   520662 Nov  7  2019 guice-4.2.1-no_aop.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 guice.license
-rw-r--r--   1 khmarbaise  staff   283858 Nov  7  2019 jansi-1.17.1.jar
drwxr-xr-x  10 khmarbaise  staff      320 Nov  7  2019 jansi-native
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 jansi.license
-rw-r--r--   1 khmarbaise  staff     2497 Nov  7  2019 javax.inject-1.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 javax.inject.license
-rw-r--r--   1 khmarbaise  staff    16539 Nov  7  2019 jcl-over-slf4j-1.7.29.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 jcl-over-slf4j.license
-rw-r--r--   1 khmarbaise  staff   397115 Nov  7  2019 jsoup-1.12.1.jar
-rw-r--r--   1 khmarbaise  staff     1192 Nov  7  2019 jsoup.license
-rw-r--r--   1 khmarbaise  staff     5848 Nov  7  2019 jsr250-api-1.0.jar
-rw-r--r--   1 khmarbaise  staff    20545 Nov  7  2019 jsr250-api.license
-rw-r--r--   1 khmarbaise  staff    57824 Nov  7  2019 maven-artifact-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff    14262 Nov  7  2019 maven-builder-support-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff   287955 Nov  7  2019 maven-compat-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff   633028 Nov  7  2019 maven-core-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff    98096 Nov  7  2019 maven-embedder-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff   215412 Nov  7  2019 maven-model-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff   192302 Nov  7  2019 maven-model-builder-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff    47035 Nov  7  2019 maven-plugin-api-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff    27158 Nov  7  2019 maven-repository-metadata-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff   148983 Nov  7  2019 maven-resolver-api-1.4.1.jar
-rw-r--r--   1 khmarbaise  staff    44143 Nov  7  2019 maven-resolver-connector-basic-1.4.1.jar
-rw-r--r--   1 khmarbaise  staff   180696 Nov  7  2019 maven-resolver-impl-1.4.1.jar
-rw-r--r--   1 khmarbaise  staff    66242 Nov  7  2019 maven-resolver-provider-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff    36732 Nov  7  2019 maven-resolver-spi-1.4.1.jar
-rw-r--r--   1 khmarbaise  staff    31013 Nov  7  2019 maven-resolver-transport-wagon-1.4.1.jar
-rw-r--r--   1 khmarbaise  staff   167529 Nov  7  2019 maven-resolver-util-1.4.1.jar
-rw-r--r--   1 khmarbaise  staff    44047 Nov  7  2019 maven-settings-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff    42090 Nov  7  2019 maven-settings-builder-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff   166562 Nov  7  2019 maven-shared-utils-3.2.1.jar
-rw-r--r--   1 khmarbaise  staff    23815 Nov  7  2019 maven-slf4j-provider-3.6.3.jar
-rw-r--r--   1 khmarbaise  staff   379197 Nov  7  2019 org.eclipse.sisu.inject-0.3.4.jar
-rw-r--r--   1 khmarbaise  staff    11530 Nov  7  2019 org.eclipse.sisu.inject.license
-rw-r--r--   1 khmarbaise  staff   205323 Nov  7  2019 org.eclipse.sisu.plexus-0.3.4.jar
-rw-r--r--   1 khmarbaise  staff    11530 Nov  7  2019 org.eclipse.sisu.plexus.license
-rw-r--r--   1 khmarbaise  staff    13350 Nov  7  2019 plexus-cipher-1.7.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 plexus-cipher.license
-rw-r--r--   1 khmarbaise  staff     4225 Nov  7  2019 plexus-component-annotations-2.1.0.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 plexus-component-annotations.license
-rw-r--r--   1 khmarbaise  staff    85327 Nov  7  2019 plexus-interpolation-1.25.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 plexus-interpolation.license
-rw-r--r--   1 khmarbaise  staff    27703 Nov  7  2019 plexus-sec-dispatcher-1.4.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 plexus-sec-dispatcher.license
-rw-r--r--   1 khmarbaise  staff   261801 Nov  7  2019 plexus-utils-3.2.1.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 plexus-utils.license
-rw-r--r--   1 khmarbaise  staff    41424 Nov  7  2019 slf4j-api-1.7.29.jar
-rw-r--r--   1 khmarbaise  staff     1224 Nov  7  2019 slf4j-api.license
-rw-r--r--   1 khmarbaise  staff    11586 Nov  7  2019 wagon-file-3.3.4.jar
-rw-r--r--   1 khmarbaise  staff  2206349 Nov  7  2019 wagon-http-3.3.4-shaded.jar
-rw-r--r--   1 khmarbaise  staff    55776 Nov  7  2019 wagon-provider-api-3.3.4.jar

All files which are like maven-core.. etc. are containing the version number of Maven (3.6.3) also the problematic

-rw-r--r--   1 khmarbaise  staff  2591373 Nov  7  2019 guava-25.1-android.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 guava.license
-rw-r--r--   1 khmarbaise  staff   520662 Nov  7  2019 guice-4.2.1-no_aop.jar
-rw-r--r--   1 khmarbaise  staff    11560 Nov  7  2019 guice.license

You see that this is in particular different to the given output you have where only file:/usr/share/maven/lib/guice-4.2.1-no_aop.jar apart from the missing version number of the other artifacts.

That means the problem is based on the usage of Ubuntu Maven and NOT using Apache Maven which is compatible with JDK 7 where as the repackaged version of Ubuntu is simply not.

The simplest solution is to remove the ubuntu Package of Maven and install the original Apache Maven https://maven.apache.org/download.cgi then the build with JDK 7 will work. (Download and check the checksums etc.)

Also you can download the Apache Maven and check the checksums of files against the ones of your distro (/usr/share/maven/lib/) I bet that all files are different.

The issue is based on the idea of distros to repackage Application (for example Maven) with their dependencies which are on their system which in reality means you have different versions of dependencies which results in such issues.

Sex answered 11/5, 2021 at 7:15 Comment(7)

Great analysis and definitely the correct approach to solving this. But I wouldn't go as far as saying that the Ubuntu package of Maven is "not Apache Maven". It's simply a repackaging that happens to have a bug in it. Providing packages for existing software is a far cry from making it "not that software". I'd say something like "you're not using the software as distributed by Apache" or similar. – Philology 11/5, 2021 at 7:22

The repackaged variant is not Apache Maven anymore because it violates the checksums and also the GPG signatures. It violates integrity of the package. That's it. Apart from that it does not make sense to repackage an existing and tested software (in particular in Java world) which exactly is shown by this issue (That's not the only one; I seeing several issues like this). The distribution is exactly what I wrote at the beginning. A package which has it's checksums and also is signed by GPG. – Sex 11/5, 2021 at 7:27

I agree with all the issues that you mention and think that packaging Java software like this is a bad idea. But saying "it is not Apache Maven" seems nonsensical, because it is Apache Maven, as it's built from their exact sources. What you're saying implies that no Linux Distribution ships with the Linux kernel (because they all patch and recompile it) or Firefox or Gnome. – Philology 11/5, 2021 at 7:30

The source is not enough it means also the dependencies. And then my question: Why rebuilding? It's existing as ready consumable artifact? The point of view is here the problem. In distro world you look at the source only and rebuild for different distros (cpu's etc./patching is different thing?) But in Java it is not needed nor will solve any problem more on the contrary it produces issues. – Sex 11/5, 2021 at 7:36

The point is checksums/gpg signing is done on the resulting artifacts (which includes all the deps etc.) not the source and that integrity is violated by rebuilding from source (apart from replacing deps; which does not make sense breaking all tests which have been made)... – Sex 11/5, 2021 at 7:40

One point I missed. On a released package (Apache Maven 3.6.3) has been done a lot of testing on it (via ci etc.) running on different JDK's etc. Those tests have to be repeated by the distros but this issue shows it is not done that way. – Sex 11/5, 2021 at 7:50

I agree with all of the issues you mention (which are basically artifacts of the disconnect between Linux distribution "philosophy" and how Java software is handled) and I try to avoid using re-packaged Java software for these reasons. The only point where I disagree with you is that somehow those all mean that repackaging can't be the same software. The binary distribution released is not the only artifact that Maven releases. If only that was considered "Apache Maven", then why release the source package at all (curious parties and developers can just pull from git after all)? – Philology 11/5, 2021 at 7:54

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags