Relationship between this plugin and Gradle's improved pom support

[twwwt]

With the new features of (i) dependency constraints and (ii) importing a BOM that have been released with Gradle 4.6, should we consider this plugin deprecated? Asked differently, are there any use cases that this plugin supports in addition to what Gradle supports since 4.6 and that would therefore motivate still using this plugin?

In case this plugin can be considered deprecated, I would like to propose adding a deprecation note to the readme, similar to how this was done for the nebula-dependency-recommender-plugin.

[wilkinsona]

With the new features of (i) dependency constraints and (ii) importing a BOM that have been released with Gradle 4.6, should we consider this plugin deprecated?

No, not yet anyway.

are there any use cases that this plugin supports in addition to what Gradle supports since 4.6 and that would therefore motivate still using this plugin?

Yes. This plugin does three things differently to Gradle's native support at the time of writing.

1. Applies versions in an imported bom as Maven intends. Specifically, the version in a bom will control the version of any direct or transitive dependency that is managed by the bom.
2. Allows properties in a bom to be overridden to easily control the version of multiple managed dependencies.
3. Applies exclusions declared in a dependency's pom as Maven intended.

I would like to propose adding a deprecation note to the readme, similar to how this was done for the nebula-dependency-recommender-plugin.

I'd really like for that to be the right thing to do, but we're not there yet (see items listed above) and I fear we'll never get there.

I'm going to leave this open for now as a source of information for others. Once Gradle's functionality has been promoted such that it's no long hidden behind a feature flag, we can take some action here. I suspect that'll end up being a change to the README that explains the differences and offers some guidance on when you may want to choose one approach over the other.

[twwwt]

a change to the README that explains the differences and offers some guidance on when may want to choose one approach over the other

That describes precisely why I was raising this issue: I need some guidance. Thanks for clearing up matters, especially bullets 1. to 3. are very helpful.

[bric3]

@wilkinsona Now that Gradle 5 is out, is there an update to make in this regard ?

[wilkinsona]

I'll hopefully get a chance to write up something more detailed, but in a nutshell two of the differences outlined above still exist. Gradle 5 addresses bullet 1 with the concept of an enforced platform. Bullets 2 and 3 have not been addressed. If you're in a position to use Gradle 5, I would recommend trying to use an enforced platform and seeing how far you get.

[mrozanc]

Hello, do you plan to use the new gradle dependency management features in the plugin implementation? It would be nice to have a compatibilty between the platform approach and this plugin features.
I tried the platforms and I had many issues I don't have with the plugin: the platform doesn't support maven profiles triggered by system properties, it fails importing a bom in the platform and overriding the version of one of the artifacts in the same platform if we use the enforcedPlatform way, importing a bom in a platform requires to allow dependencies in the platform, you can't do it in the constraint part.
However, the constraint API is nice and it's very useful to be able to reference projects in the platform, in order to publish our own bom and reference it in our modules too.

[wilkinsona]

No, I don't. The plugin will remain a separate alternative to Gradle's native bom support. If you are bumping up against limitations in Gradle's own support, please feed that back to the Gradle team.

[chhex]

I think this is a very important point. Spring , specifically Spring Boot has lead the way for the community and has - like with many other things - provided and supported actively best practice. Having said all this, my request for clarification maybe wrong here. But it seems that, some how this kind of question falls between the chair and the bench from a users perspective. And Spring has a great track record to address exactly these kind of situations.

Just for clarification the following Gradle code as a simple example, which is valid since Gradle 5.0.x:

dependencies {
    implementation(platform("org.springframework.boot:spring-boot-dependencies:2.1.4.RELEASE"))
    implementation("commons-codec:commons-codec")
    implementation("org.yaml:snakeyaml:1.24")
}
}

should produce in general the same direct and transitive dependency versions as

dependencyManagement {
     imports {
          mavenBom "org.springframework.boot:spring-boot-dependencies:2.1.4.RELEASE"
     }
}
dependencies {
    implementation("commons-codec:commons-codec")
    implementation("org.yaml:snakeyaml:1.24")
}

If a artifact is declared in the imported mavenBom.

This seems not to be the case, see

Applies versions in an imported bom as Maven intends. Specifically, the version in a bom will control the version of any direct or transitive dependency that is managed by the bom.
?

[wilkinsona]

As far as I can tell, your example produces the same two dependencies in both cases:

• commons-codec:commons-codec:1.11
• org.yaml:snakeyaml:1.24

There are scenarios where there may be differences, however, particularly as you are using Gradle's platform rather than enforcedPlatform. The former expresses an opinion about dependency versions that is fed into constraint resolution. The latter expresses a strict requirement.

[chhex]

Great thanks! Without having looked into Gradle new API's in this regard: Is fair it enough to say that Spring DependencyManagement and enforcedPlatform produce the same results , except that with Spring DependencyManagement - as you stated - one can overwrite maven property values of the Bom and that Spring Dependency Management applies exclusions declared in a dependency's pom. The Later naturally being critical, since it means as soon there are exclusions in a pom, Gradle and Spring Dependency Management will always produce different results , for that also Gradle and Maven?

[wilkinsona]

From #262 (comment), it's worth noting in the documentation changes that come from this issue how to configure Gradle's metadata to use the resolved versions that have been influenced by the dependency management plugin.

[wilkinsona]

Is fair it enough to say that Spring DependencyManagement and enforcedPlatform produce the same results

Yes, in terms of dependency versions that should be the case.

as soon there are exclusions in a pom, Gradle and Spring Dependency Management will always produce different results

Not necessarily always, but it's likely.

[ayush-finix]

Are there any updates to this with the release of gradle 6.6.1?

[wilkinsona]

@ayush-finix What have you seen in Gradle 6.6.1 that you expect to have changed the situation?

[smoothreggae]

I just upgraded Gradle from 3.5.1 to 6.7 for a few builds a couple of weeks ago. I noticed something in a couple of projects that seems related to this ticket (and #262).

Both projects (let's call them A and B) use the Spring Dependency Management Plugin. A imports a BOM for the versions of a set of dependencies. B cites A as an "implementation" dependency. After upgrading the builds of A and B to Gradle 6.7 and publishing artifacts from A, I noticed that the build in B failed to get the versions of the dependencies that were managed by the BOM that A was importing. ./gradlew dependencies also indicated this with a FAILED at that node in the tree. It turns out that this was because the build in A had started publishing Gradle Module Metadata and adding a special comment block at the top of the published POM that told Gradle in the build of B to use the module metadata instead. The only way to keep things working as they used to before the upgrade was to add the following to build.gradle for A:

tasks.withType(GenerateModuleMetadata) {
    enabled = false
}

With this, it looks like the builds will continue to use the Spring Dependency Management plugin without being affected by internal changes in Gradle to support native BOM support (the differences, as you have noted in previous comment, are important enough for us to continue to stick with the Spring Dependency Management plugin)

[wilkinsona]

Thanks, @smoothreggae. An alternative is to configure project A to use resolved versions in the metadata as mentioned above.

[ericparton]

Yes. This plugin does three things differently to Gradle's native support at the time of writing.

1. Applies versions in an imported bom as Maven intends. Specifically, the version in a bom will control the version of any direct or transitive dependency that is managed by the bom.
2. Allows properties in a bom to be overridden to easily control the version of multiple managed dependencies.
3. Applies exclusions declared in a dependency's pom as Maven intended.

I think there's good news with regards to your third point there. gradle/gradle#22866 appears to fix the issue with reading exclusions from Maven poms. Assuming that's actually the case, that would just leave the lack of the ability to override pom properties as the main issue.

[wilkinsona]

Thanks, @ericparton. Unfortunately, I don't think this aligns the behavior around exclusions. As far as I am aware, the difference in behavior that's described in this plugin's documentation still exists.

[hazendaz]

This ticket helped us figure this out with spotbugs + checkstyles latest with gradle. So this is still an issue with gradle 8.5 and this plugin resolves it nicely for us. Thanks.