Enforcer implementation must change due to Gradle 7 #17
Assignees
Labels
Comments
|
Watch out for gradle/gradle#15522 |
|
It fails with Gradle 7, plugin version 0.9.0: |
|
If another release of the plugin occurs before you are able to fix this issue perhaps add a version check and fail to run if Gradle 7+ is being used. (As usual I flailed for a while thinking the problem was my fault before learning that it wasn't expected to work). |
|
@bondolo I'm waiting til Gradle 7.3 comes out to have another go at migration. Why that particular release? Because Gradle has a history of unstable releases after a major release. Things usually settle after a couple of minor releases are posted. |
|
same issue with gradle 7.3.1 |
|
get the same issue on gradle 7.4.0 |
|
Are you applying the plugin at the right place? Note that there are 2 plugins https://kordamp.org/enforcer-gradle-plugin/#_applying_the_plugin |
|
@aalmiray , ah, right, I use it at project level, it works after use the 'org.kordamp.gradle.project-enforcer'. thx |
|
Is this still an issue? I tried with Gradle 8.1.1 and enforcer plugin 0.13.0 and didn't see build failure or warning message. |
|
@bmuschko That's strange. That would mean a warning that used to appear in Gradle 7 was removed while the deprecated behavior was kept in place. I think that's highly unlikely but also I have not read through the releases notes for 8 to check if the old behavior was deemed acceptable in the end. |
|
@aalmiray My build script: Does this only happen with the |
|
Ah I see. |
|
Gotcha. Do you have plans to fix this issue? |
|
I have not come up with a plan that would let the |
|
I'm not sure is my problem is related to this issue, or if I should file a separate issue. However, when I add an "enforce" block to // Do read the documentation on Enforcer to pick what makes sense to you:
// https://kordamp.org/enforcer-gradle-plugin/#_rule_dsl
/*
enforce {
configure()
rule()
}
*/I feel I'm doing something wrong, however I'm following the documentation, and have tried several variations. |
|
@aalmiray: Following up to see what status is on this issue. @jwlibby and I work on a book for examples in the JVM world with Gradle and Maven on good practices in the build pipeline (local development, CI [ie, GitHub actions]). We have Enforcer for Maven working, and would like to show examples and documentation on using Enforcer in Gradle. |
|
Status quo remains. This plugin works with Gradle 8.x despite the warnings issued when AFAICT the This being said, the use of |
|
@aalmiray Thank you for such good information! |
|
@aalmiray I have this working now, thank you!
Two observations:
Here is the buildscript {
repositories {
gradlePluginPortal()
mavenCentral()
}
dependencies {
classpath "org.apache.commons:commons-lang3:3.15.0"
classpath "org.kordamp.gradle:enforcer-gradle-plugin:$enforcerPluginVersion"
}
}
apply plugin: "org.kordamp.gradle.enforcer"
enforce {
rule(enforcer.rules.RequireGradleVersion) { r ->
r.version = "$gradleWrapperVersion" // Pulled in from "gradle.properties"
}
} |
|
Applying the plugin in Applying the plugin in I don't have concrete experience with versions catalog but I venture I guess they are not available during evaluation of the I suppose I could upgrade dependencies and release a newer version. |
|
@aalmiray Cool. I'll see if I can do the same with When I get it working, I'll post my sample |
|
Plugins applied in |
|
I like that explanation. It makes sense. |
|
In its current state, yes I'd agree a distinction may be needed. But given that the |
|
I'd be happy to contribute example snippets once the plugin project is ready. |
|
Thank you. I'll post a release in the coming days. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current enforcer (
0.8.0) will output a warning when rules related to artifact resolution are configured in a build. This warning occurs becausesettingsresolves configurations belonging to a project, and that's a big no-no in Gradle 7.The fix is to resolve configurations with a task that's registered on the project. This would make dependency resolution aware rules be good citizens however that also means rules won't be executed automatically after all projects are configured but not yet executed. And here lies the problem if the current design stays put:
To complicate matters, registering a
buildFinished()listener is also a no go in Gradle 7 due to configuration cache (currently incubating since 6.6.). It may be the case that some rules will have to be removed or their effectiveness may become limited. It's unclear as of now if a combination of automatic execution as it's right now (early rules) and enforce tasks (dependency resolution aware) would be a good fit. Or perhaps all rules should be executed via tasks. Whatever the case it's likely that enforcer rules may not be compliant with configuration cache, in which case if that feature becomes stringent then enforcer may not be possible at some point.The text was updated successfully, but these errors were encountered: