New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Gradle Kotlin DSL #334

Open
sdeleuze opened this Issue Jan 2, 2017 · 20 comments

Comments

Projects
None yet
7 participants
@sdeleuze
Contributor

sdeleuze commented Jan 2, 2017

Linked to #331, I think it could make sense to support Gradle builds written in Kotlin instead of Groovy.

I am experimenting on that for a few month, and it works pretty well, see for example mixit or spring-boot-kotlin-demo build.gradle.kts. As a bonus, that would be nice to make that the default for Kotlin project.

This feature is also valuable for Java projects since it provides full autocomplete and validation of Gradle builds unlike the Groovy variant.

This feature works with regular IntelliJ IDEA Kotlin plugin, but you need to use Kotlin 1.1 EAP plugin to get autocomplete and validation of your build file.

I plan to contribute this feature, that IMO makes sense as part of the Kotlin support provided by Spring Framework 5 (so a good fit with Spring Boot 2.0).

@snicoll

This comment has been minimized.

Show comment
Hide comment
@snicoll

snicoll Jan 3, 2017

Contributor

This comes with several challenges. Right now, the UI (and the metadata) offers a "Maven-based" or "Gradle-based" project/build. The introduction of Kotlin makes it a "flavor" of a build type for which we have no concept right now. I am not keen to introduce one.

Also, this would be really weird to offer a way to build a Kotlin-based build with Groovy and a Groovy-based build with Kotlin.

As things stand, I'd be in favor of waiting for it to become a bit more mainstream and use it when a Kotlin project type is created. We might do the same thing for Java type, probably later.

Any other opinion?

Contributor

snicoll commented Jan 3, 2017

This comes with several challenges. Right now, the UI (and the metadata) offers a "Maven-based" or "Gradle-based" project/build. The introduction of Kotlin makes it a "flavor" of a build type for which we have no concept right now. I am not keen to introduce one.

Also, this would be really weird to offer a way to build a Kotlin-based build with Groovy and a Groovy-based build with Kotlin.

As things stand, I'd be in favor of waiting for it to become a bit more mainstream and use it when a Kotlin project type is created. We might do the same thing for Java type, probably later.

Any other opinion?

@wilkinsona

This comment has been minimized.

Show comment
Hide comment
@wilkinsona

wilkinsona Jan 3, 2017

Contributor

Can we automatically generate a Kotlin-powered build.gradle.kts when the users selects Gradle as the build system and Kotlin as the language? That way we'd avoid another UI option at least.

Contributor

wilkinsona commented Jan 3, 2017

Can we automatically generate a Kotlin-powered build.gradle.kts when the users selects Gradle as the build system and Kotlin as the language? That way we'd avoid another UI option at least.

@snicoll

This comment has been minimized.

Show comment
Hide comment
@snicoll

snicoll Jan 3, 2017

Contributor

Looks like I did a terrible job at phrasing my proposal. That's exactly what I meant.

Contributor

snicoll commented Jan 3, 2017

Looks like I did a terrible job at phrasing my proposal. That's exactly what I meant.

@sdeleuze

This comment has been minimized.

Show comment
Hide comment
@sdeleuze

sdeleuze Jan 3, 2017

Contributor

Sure we could, but I tend to think it would be better to be explicit. From both user and Initilizr POV, Gradle Groovy and Gradle Kotlin are 2 distinct build systems.

Gradle Kotlin will be IMO quickly asked by Java users given the huge gain in term of autocomplete and validation. On the other way, some people creating Kotlin projects will still want to use Gradle Groovy flavor because for example it is the only thing supported in there company or they want to keep using something stable they know for a very long time.

The combo box allowing selecting the build system contain only 2 items (Maven and Gradle), so I would be for simply adding a Gradle Script Kotlin line, and eventually hide this line in the UI when Groovy and Java languages are selected. When we will consider this mature enough, we will be able to unlock Gradle Script Kotlin for Java projects.

Any thoughts?

Contributor

sdeleuze commented Jan 3, 2017

Sure we could, but I tend to think it would be better to be explicit. From both user and Initilizr POV, Gradle Groovy and Gradle Kotlin are 2 distinct build systems.

Gradle Kotlin will be IMO quickly asked by Java users given the huge gain in term of autocomplete and validation. On the other way, some people creating Kotlin projects will still want to use Gradle Groovy flavor because for example it is the only thing supported in there company or they want to keep using something stable they know for a very long time.

The combo box allowing selecting the build system contain only 2 items (Maven and Gradle), so I would be for simply adding a Gradle Script Kotlin line, and eventually hide this line in the UI when Groovy and Java languages are selected. When we will consider this mature enough, we will be able to unlock Gradle Script Kotlin for Java projects.

Any thoughts?

@snicoll

This comment has been minimized.

Show comment
Hide comment
@snicoll

snicoll Jan 3, 2017

Contributor

Please, do not forget that Initiliazr has many clients and we should offer whatever customization we support to all of them. That idea of hiding stuff in the web ui is a big no no. This isn't just a line in a combo box, there is a meta-data element behind it. You need to convey that to remote clients as well.

Frankly, I'd be up to generate a Kotlin-based build with Kotlin only and see how folks react to that.

Contributor

snicoll commented Jan 3, 2017

Please, do not forget that Initiliazr has many clients and we should offer whatever customization we support to all of them. That idea of hiding stuff in the web ui is a big no no. This isn't just a line in a combo box, there is a meta-data element behind it. You need to convey that to remote clients as well.

Frankly, I'd be up to generate a Kotlin-based build with Kotlin only and see how folks react to that.

@sdeleuze

This comment has been minimized.

Show comment
Hide comment
@sdeleuze

sdeleuze Jan 4, 2017

Contributor

I will follow your recommandation, and I understand that you don't want to introduce some UI tricks, but doing another trick to generate a special Gradle Script Kotlin based build when Kotlin is the selected language seems to be the wrong path to me. How will we do when Java users will require such support? What will be our answer to users using Kotlin language but regular Gradle Groovy based build?

To me Gradle Script Kotlin (btw this name is likely to change before GA) is really another build system, and unlike in Maven World where polyglot Maven seems to stay niche, Gradle clearly said Gradle Script Kotlin is their long term default solution whatever language your use. So since Initializr supports already 2 ones, I still think we should add this as a 3rd regular one.

My hiding stuff proposal was more to provide an answer to your concern about Groovy language projects that don't want to see Gradle Script Kotlin as a build system. But IMO these are orthogonal concerns, I would just list the 3 build systems whatever language you choose, even if for sure Groovy langage project will likely to use more often regular Gradle Groovy builds and if Kotlin projects are more likely to use Gradle Script Kotlin.

Optionally, I could also contribute as a distinct issue/PR a feature that allows to specify in the metadata what is the default build tool for a specific language. In term of UI, we could select by default Groovy Gradle for Groovy project and Gradle Script Kotlin for Kotlin projects. In term of REST API that would enable to generate a project without specifying the build system in the request with the most popular one by default.

Any thoughts?

Contributor

sdeleuze commented Jan 4, 2017

I will follow your recommandation, and I understand that you don't want to introduce some UI tricks, but doing another trick to generate a special Gradle Script Kotlin based build when Kotlin is the selected language seems to be the wrong path to me. How will we do when Java users will require such support? What will be our answer to users using Kotlin language but regular Gradle Groovy based build?

To me Gradle Script Kotlin (btw this name is likely to change before GA) is really another build system, and unlike in Maven World where polyglot Maven seems to stay niche, Gradle clearly said Gradle Script Kotlin is their long term default solution whatever language your use. So since Initializr supports already 2 ones, I still think we should add this as a 3rd regular one.

My hiding stuff proposal was more to provide an answer to your concern about Groovy language projects that don't want to see Gradle Script Kotlin as a build system. But IMO these are orthogonal concerns, I would just list the 3 build systems whatever language you choose, even if for sure Groovy langage project will likely to use more often regular Gradle Groovy builds and if Kotlin projects are more likely to use Gradle Script Kotlin.

Optionally, I could also contribute as a distinct issue/PR a feature that allows to specify in the metadata what is the default build tool for a specific language. In term of UI, we could select by default Groovy Gradle for Groovy project and Gradle Script Kotlin for Kotlin projects. In term of REST API that would enable to generate a project without specifying the build system in the request with the most popular one by default.

Any thoughts?

@fitzoh

This comment has been minimized.

Show comment
Hide comment
@fitzoh

fitzoh Jan 5, 2017

Found my way here from some of the Kotlin blog posts.
Adding in Gradle Script Kotlin as a third build option seems like the simplest approach to me.
No changes to the web UI required, and it shouldn't require any updates to the intellij initializr screen either (which is where I normally use it).

I also want to say that I'm against automatically generating a Gradle Script Kotlin build file if Kotlin is selected as the language. That could potentially be pretty jarring/confusing for someone who knows gradle and is using initializr to get started with kotlin, especially if they weren't already aware that Gradle Script Kotlin exists.

fitzoh commented Jan 5, 2017

Found my way here from some of the Kotlin blog posts.
Adding in Gradle Script Kotlin as a third build option seems like the simplest approach to me.
No changes to the web UI required, and it shouldn't require any updates to the intellij initializr screen either (which is where I normally use it).

I also want to say that I'm against automatically generating a Gradle Script Kotlin build file if Kotlin is selected as the language. That could potentially be pretty jarring/confusing for someone who knows gradle and is using initializr to get started with kotlin, especially if they weren't already aware that Gradle Script Kotlin exists.

@snicoll

This comment has been minimized.

Show comment
Hide comment
@snicoll

snicoll Jan 6, 2017

Contributor

Some more brainstorming with @sdeleuze

It looks like the consensus is to let the user chose the format of the build so we need a dedicated concept for it. We've discussed the possibility to have a third element in the first combo ("Generate a") with "Gradle" and "Gradle Kotlin" or something but I am really not a fan of the idea.

We still need to figure out how that would work UI wise for us but a third combo that lists the available format seems to be one way out. For Maven that would be XML and Gradle could have Groovy and Kotlin as options.

Metadata wise, we need a "format" concept with a label and links in each "type". Each type would also define a default "format".

The CLI can be upgraded to understand this new format, something like:

To create a web/data-jpa gradle Kotlin-based project unpacked:
        $ spring init -d=web,jpa --build=gradle --format=kotlin my-dir

IDEs that do not support the concept would just provide the usual parameters and the default format would apply for them. New versions could offer a selection for the available format and pass that along the request. Regardless, this change must be fully backward compatible with existing clients.

@bclozel @wilkinsona @dsyer (and anyone else watching here) thoughts?

Contributor

snicoll commented Jan 6, 2017

Some more brainstorming with @sdeleuze

It looks like the consensus is to let the user chose the format of the build so we need a dedicated concept for it. We've discussed the possibility to have a third element in the first combo ("Generate a") with "Gradle" and "Gradle Kotlin" or something but I am really not a fan of the idea.

We still need to figure out how that would work UI wise for us but a third combo that lists the available format seems to be one way out. For Maven that would be XML and Gradle could have Groovy and Kotlin as options.

Metadata wise, we need a "format" concept with a label and links in each "type". Each type would also define a default "format".

The CLI can be upgraded to understand this new format, something like:

To create a web/data-jpa gradle Kotlin-based project unpacked:
        $ spring init -d=web,jpa --build=gradle --format=kotlin my-dir

IDEs that do not support the concept would just provide the usual parameters and the default format would apply for them. New versions could offer a selection for the available format and pass that along the request. Regardless, this change must be fully backward compatible with existing clients.

@bclozel @wilkinsona @dsyer (and anyone else watching here) thoughts?

@wilkinsona

This comment has been minimized.

Show comment
Hide comment
@wilkinsona

wilkinsona Jan 7, 2017

Contributor

Adding a format option feels overly complicated to me, particularly as it would only be applicable to Gradle (unless we're going to support polyglot Maven too). My vote would be for a third build option. Sorry, @snicoll

Contributor

wilkinsona commented Jan 7, 2017

Adding a format option feels overly complicated to me, particularly as it would only be applicable to Gradle (unless we're going to support polyglot Maven too). My vote would be for a third build option. Sorry, @snicoll

@dsyer

This comment has been minimized.

Show comment
Hide comment
@dsyer

dsyer May 12, 2017

Contributor

I agree with Andy. It's not going to get combinatorial - there are just a couple more options in the build format.

Contributor

dsyer commented May 12, 2017

I agree with Andy. It's not going to get combinatorial - there are just a couple more options in the build format.

@wilkinsona

This comment has been minimized.

Show comment
Hide comment
@wilkinsona

wilkinsona May 23, 2017

Contributor

@bclozel @snicoll and I were discussing this a bit again today, and apparently I've changed my mind a bit from what I said in January.

I still dislike the format option, i.e. I don't want the main sentence to have a dropdown for Gradle/Maven or another for the build system format (Groovy/Kotlin for Gradle and, I guess, XML/Groovy for Maven).

In terms of the Web UI, I'd be quite happy to see one of:

  1. A single dropdown that offers Maven, Gradle (Groovy), and Gradle (Kotlin) in the main heading.
  2. The existing Maven/Gradle option in the main heading and an advanced option when Gradle is chosen for choosing Groovy or Kotlin.
  3. No option at all for choosing between Groovy or Kotlin and we just switch when Gradle Script Kotlin reaches a tipping point (if it fulfils its potential, I think reaching that tipping point is inevitable)
Contributor

wilkinsona commented May 23, 2017

@bclozel @snicoll and I were discussing this a bit again today, and apparently I've changed my mind a bit from what I said in January.

I still dislike the format option, i.e. I don't want the main sentence to have a dropdown for Gradle/Maven or another for the build system format (Groovy/Kotlin for Gradle and, I guess, XML/Groovy for Maven).

In terms of the Web UI, I'd be quite happy to see one of:

  1. A single dropdown that offers Maven, Gradle (Groovy), and Gradle (Kotlin) in the main heading.
  2. The existing Maven/Gradle option in the main heading and an advanced option when Gradle is chosen for choosing Groovy or Kotlin.
  3. No option at all for choosing between Groovy or Kotlin and we just switch when Gradle Script Kotlin reaches a tipping point (if it fulfils its potential, I think reaching that tipping point is inevitable)
@snicoll

This comment has been minimized.

Show comment
Hide comment
@snicoll

snicoll Jun 11, 2017

Contributor

@bclozel @snicoll and I were discussing this a bit again today, and apparently I've changed my mind a bit from what I said in January.

Did you? Reading back your initial comment, 1. looks exactly like it to me.

Contributor

snicoll commented Jun 11, 2017

@bclozel @snicoll and I were discussing this a bit again today, and apparently I've changed my mind a bit from what I said in January.

Did you? Reading back your initial comment, 1. looks exactly like it to me.

@sdeleuze sdeleuze changed the title from Support Gradle Script Kotlin builds to Support Gradle Kotlin DSL Jun 19, 2017

@sdeleuze sdeleuze changed the title from Support Gradle Kotlin DSL to Support Gradle with Kotlin DSL Jun 19, 2017

@sdeleuze

This comment has been minimized.

Show comment
Hide comment
@sdeleuze

sdeleuze Jun 19, 2017

Contributor

More information about the new name: gradle/kotlin-dsl#182 (comment).

Contributor

sdeleuze commented Jun 19, 2017

More information about the new name: gradle/kotlin-dsl#182 (comment).

@wilkinsona

This comment has been minimized.

Show comment
Hide comment
@wilkinsona

wilkinsona Jun 19, 2017

Contributor

Did you? Reading back your initial comment, 1. looks exactly like it to me.

Wow, ok, so I haven't changed my mind after all. Sorry for the noise.

Contributor

wilkinsona commented Jun 19, 2017

Did you? Reading back your initial comment, 1. looks exactly like it to me.

Wow, ok, so I haven't changed my mind after all. Sorry for the noise.

@sdeleuze sdeleuze changed the title from Support Gradle with Kotlin DSL to Support Gradle Kotlin DSL Aug 16, 2017

@jhvhs

This comment has been minimized.

Show comment
Hide comment
@jhvhs

jhvhs Feb 26, 2018

@snicoll @sdeleuze @wilkinsona Has this issue been forgotten?
Every time I start a project, I have to convert the build.gradle to build.gradle.kts
by hand. It probably does make sense to enable it by default for Kotlin projects.
E.g. if I'm creating a Kotlin project, I would prefer Kotlin gradle build files. Unlike
the groovy ones, they provide proper syntax support within IntelliJ.

On the other hand, I don't know whether eclipse/vim/other developers would
gain any value from that.

I'd be more than happy to contribute.

jhvhs commented Feb 26, 2018

@snicoll @sdeleuze @wilkinsona Has this issue been forgotten?
Every time I start a project, I have to convert the build.gradle to build.gradle.kts
by hand. It probably does make sense to enable it by default for Kotlin projects.
E.g. if I'm creating a Kotlin project, I would prefer Kotlin gradle build files. Unlike
the groovy ones, they provide proper syntax support within IntelliJ.

On the other hand, I don't know whether eclipse/vim/other developers would
gain any value from that.

I'd be more than happy to contribute.

@sdeleuze

This comment has been minimized.

Show comment
Hide comment
@sdeleuze

sdeleuze Mar 12, 2018

Contributor

Before moving forward on this support on initializr side, I tend to think there is a point we should discuss with @wilkinsona and @snicoll.

Gradle Kotlin DSL makes almost mandatory to use the "new" Gradle plugins block instead of the current buildscript + apply plugin ones in order to generates static accessors that allow a syntax close to Groovy DSL.

Switching to plugins blocks could also be appealing for Groovy DSL users, since it seems to be best practice recommended by Gradle team. But I tend to consider gradle/gradle#3902 as a blocker for start.spring.io.

Any thoughts? What about creating a dedicated issue here to discuss migration to plugins block for Gradle builds (Groovy DSL for now, later Kotlin DSL as well) and contacting Gradle team to highlight that gradle/gradle#3902 is blocking us for both plugins and Kotlin DSL support?

Contributor

sdeleuze commented Mar 12, 2018

Before moving forward on this support on initializr side, I tend to think there is a point we should discuss with @wilkinsona and @snicoll.

Gradle Kotlin DSL makes almost mandatory to use the "new" Gradle plugins block instead of the current buildscript + apply plugin ones in order to generates static accessors that allow a syntax close to Groovy DSL.

Switching to plugins blocks could also be appealing for Groovy DSL users, since it seems to be best practice recommended by Gradle team. But I tend to consider gradle/gradle#3902 as a blocker for start.spring.io.

Any thoughts? What about creating a dedicated issue here to discuss migration to plugins block for Gradle builds (Groovy DSL for now, later Kotlin DSL as well) and contacting Gradle team to highlight that gradle/gradle#3902 is blocking us for both plugins and Kotlin DSL support?

@wilkinsona

This comment has been minimized.

Show comment
Hide comment
@wilkinsona

wilkinsona Mar 12, 2018

Contributor

I agree with your assessment, @sdeleuze. We need the, apparently arbitrary, -SNAPSHOT restriction to be removed before we can make progress here.

Contributor

wilkinsona commented Mar 12, 2018

I agree with your assessment, @sdeleuze. We need the, apparently arbitrary, -SNAPSHOT restriction to be removed before we can make progress here.

@sdeleuze

This comment has been minimized.

Show comment
Hide comment
@sdeleuze

sdeleuze Mar 13, 2018

Contributor

I have dropped a note on Gradle side to mention this is blocking for us, and worked on what could look like the generated Gradle configuration using plugins { } block.

Gradle Groovy DSL

plugins {
	id 'java'
	id 'eclipse'
	id 'org.springframework.boot' version '2.0.0.RELEASE' 
	id 'io.spring.dependency-management' version '1.0.4.RELEASE'
}

// We could use `ext { }` but IMO better to be consistent and use brackets since dependency management requires this syntax due to the dot into the name
ext['springCloudVersion'] = 'Finchley.M8'

// Overriding dependency management
ext['jackson.version'] = '2.9.4'

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8

repositories {
	mavenCentral()
	maven { url "https://repo.spring.io/milestone" }
}

dependencies {
	compile('org.springframework.boot:spring-boot-starter-web')
	compile('org.springframework.cloud:spring-cloud-stream')
	testCompile('org.springframework.boot:spring-boot-starter-test')
	testCompile('org.springframework.cloud:spring-cloud-stream-test-support')
}

dependencyManagement {
	imports {
		mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
	}
}

Gradle Kotlin DSL

plugins {
	id("java")
	id ("eclipse")
	id("org.springframework.boot") version "2.0.0.RELEASE" 
	id("io.spring.dependency-management") version "1.0.4.RELEASE"
}

// For ext properties, we need to use `val springCloudVersion by extra("Finchley.M8")` syntax
// For just defining a local value, `val springCloudVersion = "Finchley.M8"` is enough
// See also https://github.com/gradle/kotlin-dsl/issues/678
val springCloudVersion = "Finchley.M8"

// Overriding dependency management
extra["jackson.version"] = "2.9.4"

group = "com.example"
version = "0.0.1-SNAPSHOT"

java {
    sourceCompatibility = JavaVersion.VERSION_1_8
}

repositories {
	mavenCentral()
	maven("https://repo.spring.io/milestone")
}

dependencies {
	compile("org.springframework.boot:spring-boot-starter-web")
	compile("org.springframework.cloud:spring-cloud-stream")
	testCompile("org.springframework.boot:spring-boot-starter-test")
	testCompile("org.springframework.cloud:spring-cloud-stream-test-support")
}

dependencyManagement {
	imports {
		mavenBom("org.springframework.cloud:spring-cloud-dependencies:$springCloudVersion")
	}
}

Properties management may evolve in Gradle Kotlin DSL before 1.0, see gradle/kotlin-dsl#678.

Contributor

sdeleuze commented Mar 13, 2018

I have dropped a note on Gradle side to mention this is blocking for us, and worked on what could look like the generated Gradle configuration using plugins { } block.

Gradle Groovy DSL

plugins {
	id 'java'
	id 'eclipse'
	id 'org.springframework.boot' version '2.0.0.RELEASE' 
	id 'io.spring.dependency-management' version '1.0.4.RELEASE'
}

// We could use `ext { }` but IMO better to be consistent and use brackets since dependency management requires this syntax due to the dot into the name
ext['springCloudVersion'] = 'Finchley.M8'

// Overriding dependency management
ext['jackson.version'] = '2.9.4'

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8

repositories {
	mavenCentral()
	maven { url "https://repo.spring.io/milestone" }
}

dependencies {
	compile('org.springframework.boot:spring-boot-starter-web')
	compile('org.springframework.cloud:spring-cloud-stream')
	testCompile('org.springframework.boot:spring-boot-starter-test')
	testCompile('org.springframework.cloud:spring-cloud-stream-test-support')
}

dependencyManagement {
	imports {
		mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
	}
}

Gradle Kotlin DSL

plugins {
	id("java")
	id ("eclipse")
	id("org.springframework.boot") version "2.0.0.RELEASE" 
	id("io.spring.dependency-management") version "1.0.4.RELEASE"
}

// For ext properties, we need to use `val springCloudVersion by extra("Finchley.M8")` syntax
// For just defining a local value, `val springCloudVersion = "Finchley.M8"` is enough
// See also https://github.com/gradle/kotlin-dsl/issues/678
val springCloudVersion = "Finchley.M8"

// Overriding dependency management
extra["jackson.version"] = "2.9.4"

group = "com.example"
version = "0.0.1-SNAPSHOT"

java {
    sourceCompatibility = JavaVersion.VERSION_1_8
}

repositories {
	mavenCentral()
	maven("https://repo.spring.io/milestone")
}

dependencies {
	compile("org.springframework.boot:spring-boot-starter-web")
	compile("org.springframework.cloud:spring-cloud-stream")
	testCompile("org.springframework.boot:spring-boot-starter-test")
	testCompile("org.springframework.cloud:spring-cloud-stream-test-support")
}

dependencyManagement {
	imports {
		mavenBom("org.springframework.cloud:spring-cloud-dependencies:$springCloudVersion")
	}
}

Properties management may evolve in Gradle Kotlin DSL before 1.0, see gradle/kotlin-dsl#678.

@sdeleuze

This comment has been minimized.

Show comment
Hide comment
@sdeleuze

sdeleuze Jun 22, 2018

Contributor

I have sent a pull request that adds support for snapshot plugin version to Gradle.

After discussion with the Gradle team, it seems that Gradle Kotlin DSL will be usable from a performance POV (which is let's be honest a pain currently) as of Gradle 4.10 and IDEA 2018.2 by leveraging Kotlin 1.2.50 scripting improvements (among other things).

Contributor

sdeleuze commented Jun 22, 2018

I have sent a pull request that adds support for snapshot plugin version to Gradle.

After discussion with the Gradle team, it seems that Gradle Kotlin DSL will be usable from a performance POV (which is let's be honest a pain currently) as of Gradle 4.10 and IDEA 2018.2 by leveraging Kotlin 1.2.50 scripting improvements (among other things).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment