Gradle Kotlin DSL support

[ghost]

Support for Gradle Kotlin DSL would be really nice. It's my understanding that Kotlin will be the default language for Gradle scripts (https://www.youtube.com/watch?v=NMs8Z6rFnzE&feature=youtu.be&t=10m17s) sometime in the future.

This is a huge feature request and could take a lot of time to implement. Is it possible to turn off linting and only check dependencies? That's the key feature I would like to take advantage of now.

[holubec-petr]

Any progress here? Kotlin DSL becomes used more and more and support for it would be really helpful.

[DanielThomas]

The current implementation of the core and rules is entirely coupled to the Groovy AST. Its practically a complete rewrite to support Kotlin. We've also got no plans to move to the Kotlin DSL internally.

It's likelt either take a community effort, or Gradle proving core lint support.

[jcornaz]

I there any workaround in the mean time? Or it isn't possible to use the plugin from kotlin-dsl at all?

[matfax]

@jcornaz Not afaik. With other plugins, you only have to handle the interface changes. With this one, however, the plugin requires a complete rewrite, just as @DanielThomas said. I would even assume or suggest to host the rewritten version in a separate repository.

[huehnerlady]

Is there any update on this - for example if it will be considered? I am looking for a dependency analyse plugin for gradle - but unfortunately we use the kotlin DSL :(

[3flex]

I would even assume or suggest to host the rewritten version in a separate repository

@matfax Might that be under the nebula-plugins organisation or do you see it as completely managed externally?

I'd be interested in building a solution but couldn't commit as an individual to supporting long-term as I could only do that in my spare time.

[TWiStErRob]

Do I understand correctly that this limitation exists because you're parsing the dependencies blocks rather than hooking into the resolved configurations Gradle provides in-memory? Or is the limitation only "auto-removing" bad dependencies?

[DanielThomas]

The code that determines duplicate classes, unnecessary dependencies, etc do just look at the configurations and work regardless of DSL language and it is possible to fire violations against the build file without being AST aware. That said rules are Groovy AST based even when they rely on the configuration (undeclared/declared dependencies/etc) and would need work to make them fallback for Kotlin DSL. We still have no plans to support the Kotlin DSL, but would review and accept PRs that made these work at a project rather than build script aware level.

[wakedeer]

Oh, It makes me sad

[3flex]

We still have no plans to support the Kotlin DSL

Will that be revisited? https://blog.gradle.org/kotlin-dsl-is-now-the-default-for-new-gradle-builds

[DanielThomas]

Gradle changing the default doesn't change the thousands of projects we have using the Groovy DSL. We'd only implement Kotlin DSL support if we decided to switch internally, and that's unlikely, we don't see the value.

[mxkmn]

Please write about the lack of .kts support at the beginning of the readme!

[gustavjon]

Still no plans on supporting .kts?

[Keith-Albright-Bose]

It doesn't help that the official gradle docs still link to this plugin: https://docs.gradle.org/current/userguide/performance.html#avoid_unnecessary_and_unused_dependencies Thanks for adding the doesn't work to the top of the readme. The following plugin is getting updates but has false positives. Your mileage may vary: https://github.com/autonomousapps/dependency-analysis-gradle-plugin