Kotlin-dsl-samples: Import java.net.URI in buildscript block - need to use fully qualified name?

Created on 11 Jun 2018  Â·  6Comments  Â·  Source: gradle/kotlin-dsl-samples

Just a quick question- this is my (top-level) build.gradle:

// Top-level build file where you can add configuration options common to all sub-projects/modules.
import java.net.URI

buildscript {
    repositories {
        maven { url = java.net.URI("https://maven.fabric.io/public") } // 1
        google()
        jcenter()
    }
    dependencies {
        classpath("com.android.tools.build:gradle:3.1.3")
        classpath(kotlin("gradle-plugin", version = "1.2.41"))

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        maven { url = URI("https://maven.fabric.io/public") } // 2
        google()
        jcenter()
    }
}

task<Delete>("clean") {
    delete(rootProject.buildDir)
}

And my only question is: Why do I need to use the fully qualified name java.net.URI in the line marked 1, while I don't have to in the line marked 2?

question kotlin-dsl-api

All 6 comments

Hi @DavidMihola,

The function uri(uri: String): java.net.URI is available within the buildscript block and the script body for that purpose:

     maven { url = uri("https://maven.fabric.io/public") }

There's also a maven(url: String) overload you might want to use:

     maven(url = "https://maven.fabric.io/public")

Does that help?

Hi @bamboo,

thanks a lot for the response!

Yeah, the uri function does indeed make the code look a lot cleaner.

Is there an easy explanation as to why the buildscript block works differently in this regard than, say, the allprojects block? Is it resolved before the import statements at the top are applied?

Is there an easy explanation as to why the buildscript block works differently in this regard than, say, the allprojects block? Is it resolved before the import statements at the top are applied?

Yes, the optional plugins block together with the optional buildscript block are evaluated first and separately from the rest of the script.

Closing as answered.

Thanks a lot - this explains everything!

Thanks a lot - this explains everything!

Doesn’t explain why kotlin doesn’t fall back on the void setUrl(Object var1); overload when a url = somestring is used…

Was this page helpful?
0 / 5 - 0 ratings