Hey. We trying to migrate our groovy gradle build to Kotlin DSL. But we get an issue and don’t under...

# gradle

[dwursteisen]

Hey. We trying to migrate our groovy gradle build to Kotlin DSL. But we get an issue and don’t understand how to deal with it:
we have a subproject block with a dependencies block inside. We’re trying to call the method compile in it but IntelliJ don’t find it. We missing something but we don’t see what. Have you got any idea about this?

subprojects {
   dependencies {
         compile("our dependency")
   }
}

I presume that something is missing in our scope so compile extension method is not available.

[tapchicoma]

try "compile"("our dependency")

[dwursteisen]

yeah. it works but we’re not “super super” happy about that: sometime, we’re using compile, and so in other part we may use "compile" 😫

[ribesg]

I'm not a pro in Gradle, but aren't you supposed to use implementation?

[ribesg]

Maybe compile does not work properly in kotlin-dsl because kotlin-dsl is new, and compile is an old, long-time deprecated thing

[tapchicoma]

I think migrating to new plugin dsl should solve this issue

[tapchicoma]

using classpath approach leads that you have to use either "compile" or "implementation"

[Czar]

Can you show us more of the build file? compile should be there if you have java or java-library plugin properly applied

[dwursteisen]

yes I can. I just updated some dependencies name.

buildscript {
    val commit by extra { Git.commit() }

    repositories {
        mavenLocal()
        maven { url = uri("<https://plugins.gradle.org/m2/>") }
        maven { url = uri("<https://repo.spring.io/libs-milestone>") }
    }

    dependencies {
        classpath("org.unbroken-dome.gradle-plugins:gradle-testsets-plugin:${Versions.test_sets}")
        classpath("com.internal.plugins.OurPlugin:1.2.3")
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${Versions.springboot}")
        classpath("com.google.protobuf:protobuf-gradle-plugin:${Versions.protobuf_plugin}")
    }
}

subprojects {
    apply(plugin = "OurPlugin")

    tasks.withType(Test::class).configureEach {
        reports {
            html.isEnabled = false
            junitXml.isEnabled = false
        }
        val processors = Runtime.getRuntime().availableProcessors()
        maxParallelForks = when {
            (project.name == "web") -> 1
            (processors <= 1) -> 1
            else -> processors / 2
        }
    }

    dependencies {
        "compile"("a_dependency:${Versions.margo_commons}")
    }
}

[dwursteisen]

(for information: OurPlugin apply the plugin kotlin and other plugin but not java or java-library)

[tapchicoma]

Try to migrate this:

dependencies {
        classpath("org.unbroken-dome.gradle-plugins:gradle-testsets-plugin:${Versions.test_sets}")
        classpath("com.internal.plugins.OurPlugin:1.2.3")
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${Versions.springboot}")
        classpath("com.google.protobuf:protobuf-gradle-plugin:${Versions.protobuf_plugin}")
    }
}

to new plugin api: https://docs.gradle.org/current/userguide/plugins.html#sec:plugins_block

[Czar]

buildscript is deprecated in kotlin-dsl as a plugins configuration mechanism, you have to declare plugins in plugins {} block for static accessors to be generated.

[gildor]

I would recommend to read official migration guide:
https://guides.gradle.org/migrating-build-logic-from-groovy-to-kotlin/

It covers exactly this topic (see “Configurations and dependencies” part)

[gildor]

Note that if you do not use the plugins {} block to apply your plugins, then you won’t be able to configure the dependency configurations provided by those plugins in the usual way. Instead, you will have to use string literals for the configuration names, which means you won’t get IDE support

[dwursteisen]

We went a bit too quickly on the migration 😁 we will migrate it a bit later. Thanks

[Nikky]

is there any reason to keep using the buildscript + classpath approach ?

plugins block and pluginManagement block is much cleaner, and i have yet to find something that forces me to use the classpath stuff

[ribesg]

Android.

[gildor]

Android is not a reason, you can use plugins dsl with Android

[Nikky]

is the android plugin not possible to apply throug the plugins block or is it just on a custom repository ?

[gildor]

Android Plugin is not published to Gradle Plugins portal

[Nikky]

pluginManagement {
    repositories {
        //        maven { setUrl("<http://dl.bintray.com/kotlin/kotlin-eap>") }
        maven { url = uri("<https://kotlin.bintray.com/kotlinx>") }
        mavenLocal()
        gradlePluginPortal()
    }
    resolutionStrategy {
        eachPlugin {
            if (requested.id.id == "kotlinx-serialization") {
                useModule("org.jetbrains.kotlinx:kotlinx-gradle-serialization-plugin:${requested.version}")
            }
        }
    }
}

[gildor]

but you can use resolutionManagement

[gildor]

yes, exactly

[gildor]

it’s actually shame that they didn’t publish Android Gradle plugin, at least to google repo

[Nikky]

this is for kotlinx.serialization which is also not on gradlePluginPortal and does not have the right maven coordinates to be picked up automatically

[gildor]

Please vote
https://issuetracker.google.com/issues/64551265

[Nikky]

also for your internal plugin, gradle supports -SNAPSHOT versions
deploying the plugin to mavenLocal and then testing it i na seperate project work really well for my plugin as well as deploying a snapshot version that points at the latest build so i do not have to constantly adjust buildnumbers

[gildor]

For local plugin development I would prefer composite builds than publishing to local maven

[Nikky]

composite builds ? i did not hear that term before

[tapchicoma]

https://docs.gradle.org/current/userguide/composite_builds.html

[Nikky]

gotta read up on that. seems like my way is needlessly overcomplicated

[tapchicoma]

theoretically you can also use now this new git dependency, so you don't need publish to maven local

[tapchicoma]

https://blog.gradle.org/introducing-source-dependencies

[Nikky]

well that only works once its pushed to git.. not for changes on my machine

[gildor]

Yes, source dependencies are very similar to composite builds, but for local development composite builds are just enough and also have features for now

[tapchicoma]

should be possible to use with local git:

gitRepository("/path/to/git/repo/.git")

[gildor]

but why? Composite builds are completely transparent and even do not require config or dependencies changes

[tapchicoma]

I just proposed, personally I am also for composite builds on developing locally, though it may be better to have git dependency when use just consuming plugin without developing it.

[gildor]

yeah, third party plugin is very good use case for source dependenices

[gildor]

Actuall, at the moment source dependencies could be a good solution for some Kotlin/Native or MPP stuff, because allow you to consume common code without tedious publication for all platforms

[Nikky]

do you have any example how i could use compositeBuilds to depend on a subproject of my multiproject setup ?

[Nikky]

or do i need to includeBuild the whole subproject and then depend on the subproject ?

[gildor]

You don’t need compositeBuilds for that. if you have regular multimodule project

[gildor]

composite builds make sense only if you want to include another project used as dependency

[tapchicoma]

in one project I've implemented logic that checks: if there is folder under such path - use composite build, otherwise use common dependency. Worked good.

[gildor]

Yes, this will work.
We also use another approach. We have local.settings.gradle that applied in settings.gradle (if local config exists). where you can specify any projects that you want to include also allows to have custom resourceManagement config

[Nikky]

my structure is like so:

root
  - plugin
  - test-plugin
  - libraries + other modules

[Nikky]

now i am not sure how i can make test-plugin depend on a plugin registered in plugin..

[Nikky]

i think i will stay with completely separate projects and deploying to mavenLocal for now

[gildor]

test-plugin just can use plugin without any publishing, just add it as project dependency

[Nikky]

but that will break when the plugins block in test-plugin gets resolved

[gildor]

Does your test-plugin is subproject or completely separate project?

[Nikky]

it used to be a separate project

[Nikky]

now i am trying to integrate it as a subproject

[Nikky]

dependencies {
    compile(":plugin")
}

apply {
    plugin("plugin")
}

[Nikky]

this seems to not work, cannot find the plugin

[Nikky]

ahh you said project dependency.. so that might be where it breaks

[Nikky]

i don't quite know how this is supposed to work.. the plugin has to compile between the plugin module getting resolved and the plugin-test module

[gildor]

Yeah, I’m not sure that you can apply one module to another as plugin. If test-plugin is a separate project you can easily use composite builds for that

[Nikky]

thats what i tried at first

[Nikky]

in testplugin i did includeBuild(path to root)

[Nikky]

but how do i then compile plugin which is a submodule of root ?

[gildor]

But it will compile all the submodules by default and attach as dependencies