Is there any good reason to use Gradle when you ar...

# build-tools

[Kenneth]

Is there any good reason to use Gradle when you are used to Maven?

[aandreyev]

I have recently converted from maven to gradle. I wanted to use kotlin dsl in gradle and use kotlin in the project so i have the same language for everything. I would not say i benefit much though. When you search gradle examples - it is always groovy. And because gradle is still evolving fast - search results are full of deprecated groovy gradle scrips. There are too few code samples for gradle kotlin dsl unfortunately. The multiple ways of invoking plugins and managing dependencies with no consistant syntax in examples are confusing me in gradle. So if you dont need very recent versions of kotlin compiler or some special feature, you might prefer stick with maven.

[gildor]

Kotlin DSL is still in beta and not released, Gradle docs just recently updated (and not yet released, because part of Gradle 5.0 ) to Kotlin DSL so it’s kinda expecting thing to have Groovy only samples

The multiple ways of invoking plugins

Actually, there is only one recommended way, use plugins dsl

managing dependencies with no consistant syntax

not sure what you mean

Actually, all those things covered in official migration guide:
https://guides.gradle.org/migrating-build-logic-from-groovy-to-kotlin/

But in general, I of course agree, if you not familiar with Gradle (and don’t want to become familiar) use of Kotlin DSL for you will be hard at the moment and you can see advantages of Kotlin DSL now only if you advanced user and ready to use pre-release technology

But you still can use Groovy configs, they never be deprecated and you can eventully migrate to Kotlin

But, one thing. If you familiar with Maven and everything works for you, I don’t see why you should migrate.
If you have a new project it’s more interesting choice, but still, maven officially supported by Kotlin

[aandreyev]

> managing dependencies with no consistant syntax

not sure what you mean

@gildor

i mean things like this

compile group: 'ch.qos.logback', name: 'logback-classic', version: "1.2.3"

    implementation group: 'ch.qos.logback', name: 'logback-classic', version: "1.2.3"
    implementation('ch.qos.logback:logback-classic:1.2.3')

    implementation("ch.qos.logback:logback-classic:1.2.3")

    implementation(group = "ch.qos.logback", name = "logback-classic", version = "1.2.3")

    compile("ch.qos.logback:logback-classic:1.2.3")

    compile(group = "ch.qos.logback", name = "logback-classic", version = "1.2.3")

[aandreyev]

i have 6 different ways (maybe more) to put the same thing
i do not benefit much from that kind of flexibility

[aandreyev]

plus the plugins like theese - yet another additional mechanism for dep management (intended to make things more clear and simple, i guess)

dependencyManagement {
    imports {
        mavenBom 'com.amazonaws:aws-java-sdk-bom:1.11.228'
     }
    dependencies {

[aandreyev]

if you are familiar with gradle best practicies - they are obvoius for you

[aandreyev]

but if you are switching from maven - they just confuse

[gildor]

compile and implementation have nothing with consistency, just different configurations with own behavior of class path, in this case it is very similar to Maven dependency scope, no big difference there.
Yeah, this is groovy too flexible in many situations

[gildor]

And yeah, Gradle support short and long dependency definition, I suppose long one used to be more familiar for Maven users