Hey. We trying to migrate our groovy gradle build ...
# gradle
d
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?
Copy code
subprojects {
   dependencies {
         compile("our dependency")
   }
}
I presume that something is missing in our scope so
compile
extension method is not available.
t
try
"compile"("our dependency")
d
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"
😫
r
I'm not a pro in Gradle, but aren't you supposed to use
implementation
?
Maybe
compile
does not work properly in kotlin-dsl because kotlin-dsl is new, and
compile
is an old, long-time deprecated thing
t
I think migrating to new plugin dsl should solve this issue
using
classpath
approach leads that you have to use either
"compile"
or
"implementation"
c
Can you show us more of the build file?
compile
should be there if you have
java
or
java-library
plugin properly applied
d
yes I can. I just updated some dependencies name.
Copy code
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}")
    }
}
(for information:
OurPlugin
apply the plugin
kotlin
and other plugin but not
java
or
java-library
)
t
Try to migrate this:
Copy code
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
c
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.
g
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)
👍 2
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
👍 2
d
We went a bit too quickly on the migration 😁 we will migrate it a bit later. Thanks
n
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
r
Android.
g
Android is not a reason, you can use plugins dsl with Android
n
is the android plugin not possible to apply throug the plugins block or is it just on a custom repository ?
g
Android Plugin is not published to Gradle Plugins portal
n
Copy code
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}")
            }
        }
    }
}
g
but you can use resolutionManagement
yes, exactly
it’s actually shame that they didn’t publish Android Gradle plugin, at least to google repo
1
n
this is for kotlinx.serialization which is also not on gradlePluginPortal and does not have the right maven coordinates to be picked up automatically
g
n
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
g
For local plugin development I would prefer composite builds than publishing to local maven
1
n
composite builds ? i did not hear that term before
n
gotta read up on that. seems like my way is needlessly overcomplicated
t
theoretically you can also use now this new git dependency, so you don't need publish to maven local
n
well that only works once its pushed to git.. not for changes on my machine
g
Yes, source dependencies are very similar to composite builds, but for local development composite builds are just enough and also have features for now
t
should be possible to use with local git:
Copy code
gitRepository("/path/to/git/repo/.git")
g
but why? Composite builds are completely transparent and even do not require config or dependencies changes
t
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.
g
yeah, third party plugin is very good use case for source dependenices
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
🤔 1
n
do you have any example how i could use compositeBuilds to depend on a subproject of my multiproject setup ?
or do i need to includeBuild the whole subproject and then depend on the subproject ?
g
You don’t need compositeBuilds for that. if you have regular multimodule project
composite builds make sense only if you want to include another project used as dependency
t
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.
g
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
n
my structure is like so:
Copy code
root
  - plugin
  - test-plugin
  - libraries + other modules
now i am not sure how i can make test-plugin depend on a plugin registered in plugin..
i think i will stay with completely separate projects and deploying to mavenLocal for now
g
test-plugin just can use plugin without any publishing, just add it as project dependency
n
but that will break when the plugins block in test-plugin gets resolved
g
Does your test-plugin is subproject or completely separate project?
n
it used to be a separate project
now i am trying to integrate it as a subproject
Copy code
dependencies {
    compile(":plugin")
}

apply {
    plugin("plugin")
}
this seems to not work, cannot find the plugin
ahh you said project dependency.. so that might be where it breaks
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
g
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
n
thats what i tried at first
in testplugin i did
includeBuild(path to root)
but how do i then compile plugin which is a submodule of root ?
g
But it will compile all the submodules by default and attach as dependencies