search

unbroken-dome / gradle-testsets-plugin

A plugin for the Gradle build system that allows specifying test sets (like integration or acceptance tests).
MIT License
230 stars 50 forks source link

Remove usage of deprecated APIs to run with Gradle 7 #118

Closed cpiotr closed 3 years ago

cpiotr commented 3 years ago

Gradle 7 removes some APIs which have been marked as deprecated. An example of such API is sourceSet.compileConfigurationName. Testsets plugin uses some of the removed methods which casues build failures with the following error message:

Caused by: java.lang.NoSuchMethodError:
'java.lang.String org.gradle.api.tasks.SourceSet.getCompileConfigurationName()'

Solves: #117

cpiotr commented 3 years ago

@tkrullmann, @unbroken-dome would you be able to have a look at this PR?

dsvensson commented 3 years ago

@tkrullmann PR looks great, anything blocking?

jeffbswope commented 3 years ago

We've been using a local build of this alteration without issue, for what that's worth.

The only question I'd have is whether the old behavior would need to be supported for continued support in the new version of this plugin with 6.x versions of Gradle. Which I suppose would require a lot of reflection to safely replicate the old behavior for Gradle 6.x builds without affecting Gradle 7.x builds.

Or if it's okay to say the plugin is for 7.x+ only going forward. Or if it's okay to say this plugin will going forward just stop inheriting the deprecated configurations even on Gradle versions where they haven't been removed...

This is always painful. There's some new functionality in Gradle to deal with this kind of thing and deliver plugins with different flavors for different Gradle versions, but I haven't looked into it to see how it would specifically be applied to this case: https://docs.gradle.org/7.0/userguide/implementing_gradle_plugins.html#plugin-with-variants

cpiotr commented 3 years ago

@jeffbswope, do you suggest it's not safe to assume this scenario is covered by src/integrationTest/kotlin/org/unbrokendome/gradle/plugins/testsets/GradleVersionsCompatibilityTest.kt?

jeffbswope commented 3 years ago

Unless I'm getting all turned around in my head, I think that someone who is:

Will have a (breaking) behavior change in their build when updating this plugin after this change is merged.

The test you reference just confirms it will not cause error, but this behavior change is probably noteworthy so the question would be what to do about it, if anything beyond just making it a major release of the plugin and noting the change/incompatibility.

cpiotr commented 3 years ago

@jeffbswope, gotcha, thanks for your explanation!

dsvensson commented 3 years ago

Is it possible to just drop src/main/kotlin under buildSrc while waiting for this to be merged and released? Never tried vendoring plugins before, and not getting any easily interpretable error messages. Are the required APIs perhaps not available for buildSrc use?

dsvensson commented 3 years ago

For reference wrt compatibility, the gradle shadow plugin decided to require gradle 7.0 for the new 7.0-compatible release:

https://imperceptiblethoughts.com/shadow/changes/#v7-0-0-2021-04-26

erwinw commented 3 years ago

@tkrullmann could you tell us what the plans & timelines are to resolve this issue, please, and if there are any hold-ups, perhaps let us know too, to see if we can help?

lfarkas commented 3 years ago

when will be a new release for gradle 7?

tkrullmann commented 3 years ago

Hi, thanks for the PR and sorry for the long wait! Looking at it now and hopefully going to release a new version soon.

tkrullmann commented 3 years ago

It's in the new release 4.0.0 (major version increase because strictly speaking it's still a breaking change).

I might have preferred to wrap this in a Gradle version check instead of just dropping it, but then again these configurations have been deprecated for so long that probably no-one is using them anymore. Thanks again for the contribution!