<dependencyManagement> section from the grpc-spring-boot-starter's pom cause Maven to go into an endless loop trying to resolve dependency conflict over grpc

[zartc]

When including both io.github.lognet:grpc-spring-boot-starter and io.grpc:grpc dependencies in a pom there is a non negligible risk that maven encounter a dependency conflict about the grpc libs, which it is unable to resolve and caus it to goes into an infinite loop without emmiting any disgnostic message - you must kill maven to escape the endless loop.

In an attempt to understand what was going on, I finally took a drastic action and removed the <dependencyManagement> section from the io.github.lognet:grpc-spring-boot-starter's pom in my .m2\repository\io\github\lognet\grpc-spring-boot-starter\4.8.1

Then on next run, Maven emmit the below message:

Could not resolve version conflict among [com.#####:###-commons-grpc:jar:1.0.2 -> io.grpc:grpc-services:jar:1.43.2 -> io.grpc:grpc-core:jar:[1.43.2,1.43.2], com.#####.###:protos:jar:1.0.0 -> io.grpc:grpc-netty-shaded:jar:1.49.0 -> io.grpc:grpc-core:jar:[1.49.0,1.49.0]]

ok, now I can manage to fix the issue.

The grpc dependency conflict is clearly a problem of our own, but the fact that maven goes into a endless loop without emitting a diagnostic message is a problem originating from the io.github.lognet:grpc-spring-boot-starter pom.

It may be a bug in Maven, but the fact is that removing the <dependencyManagement> section from the io.github.lognet:grpc-spring-boot-starter's pom cure the problem.

Please, can you remove the <dependencyManagement> section from the deployed pom (using, for exemple, the flatten plugin) so that maven will not goes into an endless loop in case of unresolvable grpc dependencies conflit ?

[jvmlet]

@zartc , sorry, but I'll NOT remove transitive dependency definition from the pom file, majority of users want simplicity and plug-and-play works-out-of-the-box. I strongly suggest you to NOT do this because you are likely to get some MethodDoesntExist runtime exception or unpredictable behavior, but if you insist, you should be using standards to enforce the versions you want :

• Maven
• Gradle

[zartc]

I probably badly present my case, let me explain better. I have encountered this situation where suddenly, after having upgraded a dependency in a shared lib or a parent pom then Maven goes into limbo, analyzing dependencies with cpu at 100% for hours without any sign of progress. This is a strange behavior, hard to resolve without any diagnostic message from Maven.

• The first part of the problem is a unresolvable conflict over one of the grpc libraries (we have a few shared libs that are pulling grpc libs - sometime they are not all aligned on the same grpc version). But in this case, maven fail the build with a diagnostic message explaining the situation => problem solvable.
• The second part of the problem is that for an unknow reason of me, when Maven encountered this conflict over one of the grpc libraries, the presence of the dependencyManagement section in io.github.lognet:grpc-spring-boot-starter pom put Maven into this infinite loop. Maven does not fail the build, does not print any diagnostic message, it just loop endlessly, this blocks local builds, this blocks CI builds also => without expertise this problem is unsolvable.

I understand your argument about simplicity and plug-and-play works-out-of-the-box, but don't you think that this situation deserves better than a dismissal?

[jvmlet]

Have you tried maven-enforcer-plugin to set the version you want ?

[jvmlet]

Have you ran mvn dependency:tree -Dverbose ?

[zartc]

I have tried many things: reordering dependency list, excluding transitive dependencies (I am using IntelliJ Maven Helper to see the list of dependency a la Eclipse - same as mvn dependency:tree -Dverbose), but not maven-enforcer-plugin yet, because it is not exactly what I would call a plug-and-play experience. The problem is not exactly to exclude unwanted dependencies or update the shared libs to align to the new grpc version each time we update io.github.lognet:grpc-spring-boot-starter. No, the problem is to make Maven not go into limbo blocking the build without printing any error message when it encounters this situation. As I said before, it might be a Maven bug or something, but it occurs only in the presence of io.github.lognet:grpc-spring-boot-starter regards.

[zartc]

maven-enforcer-plugin with the Banned Dependencies rules is definitively something we should add in our parent pom to force the grpc version. It will certainly not solve the root of the problem but it might prevent it to occurs by making us aware of the conflict coming from one of our shared lib. Thanks for the pointer.

[jvmlet]

The dependencyManagement section gets created by dependency-management-plugin gradle plugin https://github.com/spring-gradle-plugins/dependency-management-plugin/blob/main/src/main/java/io/spring/gradle/dependencymanagement/maven/PomDependencyManagementConfigurer.java, need to understand how to skip this

[jvmlet]

Please try 4.8.2-SNAPSHOT once this build finishes

[zartc]

@jvmlet what is the snapshot repository address ?

[jvmlet]

https://github.com/LogNet/grpc-spring-boot-starter#2-setup

[zartc]

Merci, I will test as soon as possible.

[jvmlet]

FYI, there is THE reason why some grpc versions were skipped (failing security tests /ect) because of inconsistent /buggy grpc interceptors behavior. I'm publishing this starter only with grpc versions that pass tests, as you can see, there are planty of. them.

[zartc]

almost good: there is still a compile dependency to org.springframework.boot:spring-boot-starter without a version number. This is upsetting Maven which marks its desaprobation with a warning log on the console.

[WARNING] The POM for io.github.lognet:grpc-spring-boot-starter:jar:4.8.2-20221006.150135-1 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for io.github.lognet:grpc-spring-boot-starter:4.8.2-SNAPSHOT [ERROR] 'dependencies.dependency.version' for org.springframework.boot:spring-boot-starter:jar is missing.

If you can, let this dependencies have and open range version number like [2.7.0,) and mark it as <scope>provided></scope> to prevent it to participate in the transitive dependencies list (i.e. let the user choose what version of springboot it use).

[jvmlet]

this one looks ok , please refresh your dependency and validate.

[zartc]

Well, it failed again. Your new pom 4.8.2-SNAPSHOT is ok, Maven no longer shows a warning but it returns to its endless loop behavior on resolving dependencies.

I ran several tests, each time editing the 4.8.2-SNAPSHOT pom in my .m2 directory.

The resulting observations are as follows:

1. When all the dependencies in the <dependencies> section of your pom have a valid version number, Maven enters an endless loop to resolve the dependencies.

2. When at least one dependency in the <dependencies> section of your pom does not have its version number, Maven shows a warning about this fact and finally fails the build printing the error message about the real problem: the insoluble conflict on the grpc jar.

3. When at least one dependency in the <dependencies> section of your pom has an INVALID version number (spring-boot-starter:2.7.7 for example), then Maven exhibits behavior 1 (the endless loop).

4. When both case .2 and case .3 exist in your pom, then Maven exhibits behavior 2 (failing and printing message about conflict).

My conclusion about this is:

• The problem has nothing to do with the <dependencyManagement> section of your pom.
• Its withdrawal has just induced a positive side-effect that put Maven into the case 2 where it could print a message about the real problem.
• There is no obvious links between having a dependency without its version number in the pom and having an unsolvable dependency conflict in the transitive dependency list. The first problem just prevent Maven to enter an endless loop trying to solve an unsolvable conflict.

Also

• My apologies for having taken you on a wrong track with me, you can restore your original version.
• I'll have to investigate this problem further and contact the Maven team.

[jvmlet]

It's OK, whatever it takes to see green checkmarks of tests results 😁 I hardly believe it's maven issue, because scenario is straightforward. Anyway I would upgrade maven to the latest version and recheck environment settings (proxy /etc )