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.