Wrong dependency version provided with Maven 3.8.5

pdolezal commented 2 years ago

Describe the bug

We encountered an interesting bug, which may or may not be a problem of the Quarkus Maven plugin, but might deserve verification to prevent similar problems to occur in the future, because the plugin relies on some subtleties that break under some circumstances.

The build produced a deliverable with a lower com.fasterxml.jackson.core.jackson-core library version than Maven dependency tree reported. As the result, the application crashed in runtime since some methods/classes were missing.

Observations:

The problem occurs when flatten-maven-plugin is used with the default flattenDependencyMode option.
If the dependency was specified in a more explicit way (e.g., adding quarkus-jackson as well), the version was resolved correctly.
If flattenDependencyMode is set to all, so that the flattened POM includes even transitive dependencies, the version is resolved correctly too.
If a different Maven version was used, the problem went away.

It therefore seems that the interaction with flatten-maven-plugin confuses the Quarkus plugin and results in wrong version resolution. Unfortunately, the problem is well-hidden and subtle, we discovered it just accidentally and we were astonished that the result contains a different dependency version that Maven reports as the dependency to be used.

Expected behavior

The dependencies gathered in the result should always have the same versions that Maven dependency tree reports.

Actual behavior

No response

How to Reproduce?

Here is a small application that produces the wrong version in the result when built with Maven 3.8.5. I recommend using a Docker image for that, for some reason, the problem may not appear with a locally installed Maven on some systems, while official Maven images seem to provide consistent results.

$ docker run -it --rm -v /path-to-the-reproducer/wrong-version:/build maven:3.8.4-openjdk-17 /bin/sh
$ cd /build
$ mvn clean package
$ ls target/quarkus-app/lib/main
# Contains com.fasterxml.jackson.core.jackson-core-2.13.3.jar

Try running the reproducer with maven:3.8.5-openjdk-17 instead. The result would contain then com.fasterxml.jackson.core.jackson-core-2.12.6.jar instead, while mvn dependency:tree reports com.fasterxml.jackson.core:jackson-core:jar:2.13.3.

Output of `uname -a` or `ver`

No response

Output of `java -version`

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of `mvnw --version` or `gradlew --version`)

No response

Additional information

No response

quarkus-bot[bot] commented 2 years ago

/cc @quarkusio/devtools

gsmet commented 2 years ago

@aloubyansky that's probably one for you.

famod commented 2 years ago

Just to rule that out: have you tried Maven 3.8.6 and/or latest dependency-plugin?

pdolezal commented 2 years ago

Just to rule that out: have you tried Maven 3.8.6 and/or latest dependency-plugin?

Yes, we tried 3.8.4 (working), 3.8.5 (where we found the problem originally) and 3.8.6 (working again). So, it is possible to work around the problem by using any other version than 3.8.5 and/or flatten-maven-plugin (tried with 1.2.7 and 1.3.0), but I'm afraid that the problem could appear anytime again and it could also bite other ignorant users. The worst part perhaps is that it undermined our trust to the build pipeline when our Jenkins produced such a malformed result. I therefore thing that knowing the root cause is useful.

aloubyansky commented 2 years ago

You may be running into https://issues.apache.org/jira/browse/MNG-7432 that affects 3.8.5 and was fixed in 3.8.6. We are not recommending Maven 3.8.5 to Quarkus users because of that.

pdolezal commented 2 years ago

You may be running into https://issues.apache.org/jira/browse/MNG-7432 that affects 3.8.5 and was fixed in 3.8.6. We are not recommending Maven 3.8.5 to Quarkus users because of that.

I see. Good to know that Maven 3.8.5 suffers from problems that makes it unsuitable for Quarkus. I'm not able to tell if the root cause for this particular case is the same as described in the Maven bug (there is no reactor, no profiles involved etc.), but I can't tell the opposite either. I trust your judgement and if you think that nothing should be done for Quarkus, let it be so.

Anyway thanks for the information!

aloubyansky commented 2 years ago

"Reactor" is a component of a "Maven engine", it is surely involved. The flatten-maven-plugin manipulates the POM and that could make it suffer from the mentioned bug. Which is about an inconsistency between dependency information provided, for example, through Project API and what the Maven resolver returns. The quarkus-maven-plugin relies on the Maven resolver API provided by the Maven plugin manager to resolve application dependencies. We are talking about the runtime dependencies here, there are no special tricks resolving them in the Quarkus plugin. BTW, the Maven issue I referenced isn't specific to Quarkus. I am pretty sure there are plenty of other tools and frameworks using Maven resolver API that are affected by it.

quarkusio / quarkus