In #452 a check has been introduced to fail invocation of resolve-ranges on a dependency without a version in dependencyManagement. I would argue that this is too strict and should be changed to at most a log message. First of all, maven does accept these, but second, there are scenarios where this actually is useful.
One such scenario is where a parent pom manages artifact A to version v1 and a pom B down the inheritance tree imports a bom that manages the version of artifact C which depends on another version v2 of A. In this setup maven will use v1. In order to get it to use v2 you could add a dependencyManagement to B for artifact A and version v2, but then you would be repeating the version of an artifact you don't have a direct dependency on. This also defies the purpose of using a bom.
This is the situation where dependencyManagement without a version is useful. You can add A without a version to the dependencyManagement of B and this will have maven select v2 just as we needed.
The accompanying pull request contains a minimalist example. The top level pom is called 'grandfather', artifact A is 'junit:junit', B is 'parent' and C is 'library'. If you run 'mvn dependency:tree -Dverbose=true' it will show 'junit:junit:jar:4.13.2:compile' because that is pulled in through the imported BOM. If you remove the versionless junit:junit dependency from 'parent' and run again, you will get 'junit:junit:jar:4.13.1:compile (version managed from 4.13.2)'.
I have verified this behavior with maven 3.9.11 and 4.0.0-rc-4
Ofcourse, in a real world scenario 'grandfather', 'library' and 'bom' would not be part of the same reactor, but in separate projects that are not under my control.
My pull request replaces the exception that resolve-ranges would throw now, with a log message and ignores the versionless dependency management as there is nothing to resolve there. Throwing an exception was introduced in #452 and as a result of issue 442. The reporter of this issue has indicated that he would like the resolve-ranges mojo to help indicate what the problem is and where it comes from. Throwing an exception was, as I hope to have demonstrated, not the best way forward here.
I would also like to note that core maven will already fail on regular dependencies within a version, the discussion here is strictly about dependencyManagement entries.
In #452 a check has been introduced to fail invocation of resolve-ranges on a dependency without a version in dependencyManagement. I would argue that this is too strict and should be changed to at most a log message. First of all, maven does accept these, but second, there are scenarios where this actually is useful.
One such scenario is where a parent pom manages artifact A to version v1 and a pom B down the inheritance tree imports a bom that manages the version of artifact C which depends on another version v2 of A. In this setup maven will use v1. In order to get it to use v2 you could add a dependencyManagement to B for artifact A and version v2, but then you would be repeating the version of an artifact you don't have a direct dependency on. This also defies the purpose of using a bom.
This is the situation where dependencyManagement without a version is useful. You can add A without a version to the dependencyManagement of B and this will have maven select v2 just as we needed.
The accompanying pull request contains a minimalist example. The top level pom is called 'grandfather', artifact A is 'junit:junit', B is 'parent' and C is 'library'. If you run 'mvn dependency:tree -Dverbose=true' it will show 'junit:junit:jar:4.13.2:compile' because that is pulled in through the imported BOM. If you remove the versionless junit:junit dependency from 'parent' and run again, you will get 'junit:junit:jar:4.13.1:compile (version managed from 4.13.2)'.
I have verified this behavior with maven 3.9.11 and 4.0.0-rc-4
Ofcourse, in a real world scenario 'grandfather', 'library' and 'bom' would not be part of the same reactor, but in separate projects that are not under my control.
My pull request replaces the exception that resolve-ranges would throw now, with a log message and ignores the versionless dependency management as there is nothing to resolve there. Throwing an exception was introduced in #452 and as a result of issue 442. The reporter of this issue has indicated that he would like the resolve-ranges mojo to help indicate what the problem is and where it comes from. Throwing an exception was, as I hope to have demonstrated, not the best way forward here.
I would also like to note that core maven will already fail on regular dependencies within a version, the discussion here is strictly about dependencyManagement entries.