New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NoSuchMethodError when running detekt 1.21.0-RC2 with type resolution and Kotlin 1.7.0 #5021
Comments
Can you share your project? If not, do you have a reproducer? If not, can you share a build scan? If not, can you run a Gradle dependencies report for the project that has the failing task? We'll need more than just a stack trace, it doesn't provide enough information to help unfortunately when the error is coming from the Kotlin compiler itself as it is here. |
I can't do any of those things for this particular project. I can try to make a repro project but @cortinico mentioned in the Kotlin Slack that Detekt doesn't support Kotlin 1.7 yet. |
detekt's dependencies should be isolated compared to the dependencies the project itself uses - so as long as the code in the project you're running detekt on can compile with Kotlin 1.6.21 as well, detekt should run successfully, as long as detekt's dependencies are correct. Is there some reason you can't run Here's sample output from this project, running
|
I believe Gradle uses the same dependency that I specify for transitive dependencies. So if I use Kotlin 1.7.0, then it will use that for any transitive dependencies that use Kotlin as well:
|
As I mentioned on Slack, we haven't currently bumped Kotlin to 1.7 (see #4821) so that's the root cause of your problem. Are you using another Gradle Plugin which is pulling in Kotlin 1.7? |
This was part of me upgrading my project to Kotlin 1.7 so it's the Kotlin plugin that pulls it in. It seems like I don't have any choice other than staying on 1.6.21 for now, but as I said on slack, that's less than ideal. |
We could think of releasing 1.6.21 and 1.6.22-RC1 nearly at the same time just adding support for kotlin 1.7. I agree that we shouldn't be a stopper for people updating kotlin. |
Agree as well. Still this puts pressure on our release schedule as we need to necessarily align to the Kotlin release schedule then |
Not sure if it makes sense for detekt, but I really like the way KSP handles this by having separate artifacts for different Kotlin versions (e.g. versions 1.7.0-1.0.6 and 1.6.21-1.0.6). They typically support new versions of Kotlin within a few days of it being released (if not the same day). |
The underlying issue is is basically the same as #4786 - the version of the Kotlin compiler that detekt depends on is being overridden in the project. A strict dependency on the required version (currently 1.6.21) should fix the version and not allow it to be overridden. It's being overridden here, but not sure why. @eygraber can you please run this command which hopefully explains what's causing the version to be overridden?
I'd suggest we don't have the resources to effectively test the different permutations and properly support multiple Kotlin versions simultaneously. Unfortunately all detekt maintainers are volunteers - and because detekt isn't a part of the compilation process like KSP there's less need to do this, as long as we can effectively control the dependencies used in the |
|
I'd hoped that would be more informative, but we only have "selected by rule" as the reason. How do you apply the 1.7.0 version in your build script? Is it only the Kotlin JVM plugin? Or do you do something like this as well:
|
Yup, that's it 🙈 And of course I don't have a comment reminding me why I did that 3 years ago... |
I'm assuming that I did that because I had some dependencies in the past that pinned a version of Kotlin that was causing issues. Doesn't seem to be the case anymore, but I'm still a bit hesitant to remove it. |
Are you applying it as a strict rule? Can you share the code block? We apply a strict dependency version but that shouldn't be overridden by a configuration override except when applying it strictly, so I want to know why #4822 didn't stop this happening. And to stop it overriding detekt's configuration just change the line |
I'll update it to exclude the |
Closing, as the cause was identified. It seems the strict version dependency can be overridden by a custom resolution strategy. This might be one we have to keep educating users about. |
This happens on RC1 as well. It is an Android project.
The cause is:
Full stacktrace
The text was updated successfully, but these errors were encountered: