Well, I've tried to migrate to Gradle Kotlin DSL several times, but each time I was trying to fix some obscure issues related to IDEA or build script. And now I tried again and it was my shortest attempt, because I failed on the step of renaming build.gradle to build.gradle.kts. Accidentally IDEA didn't want to recognize kotlin in this file. But well, ok, I thought I could made it without IDE support. I declared constant with kotlin version in top of the script, tried to use it in buildscript section, but compiler said "Unresolved reference". Ok, that's enough, with Groovy It has been working somehow.
Vlad Saif I am completely with you on this. A Gradle Kotlin DSL project created by the Intellij IDEA Ultimate Wizzard and completely untouched by me will not even build because an IDE issue is following another! I’m so sick of even trying to use Kotlin DSL for Gradle!
@3:46: Gradle needs 70,000 lines of groovy build logic to build Gradle itself!! And at no time did it occur to you that Gradle was a failure? You knew Gradle was extremely difficult for developers to use since very little support from IDEs was present and wouldn't be for the foreseeable future, but you still pushed Gradle as an amazing tool, a great replacement for Maven. Isn't that stupid stubbornness? With Gradle, no two Gradle scripts are alike! As projects grow and age, Gradle scripts turn into disgusting pieces of shit, because the poor guys who have to write and maintain them, knowing only 5% of Gradle's possibilities (and having no time and no desire to spend weeks learning Gradle’s arcane), immediately take the easy path of crafting custom unreadable and unmaintainable scripts, for often fantasized needs, which is really an horrible solution (it’s like being back in the days or Ant). I tried to get into Gradle several times, each time I came back to Maven with relief. With Maven things are clear and do not vary from one project to another. Maven POMs have a rigid syntax, an even cumbersome syntax yes, but that's a good thing. It prevents people from doing funky things with the POM. Either they have the know-how or they acquire the know-how. And at the end-of-the-day it is beneficial for everybody, for people that are on the project right now AND those people that will be on the project next ten or twenty years.
This presentation was horrible. It's such a shame honestly cause it could have been extremely useful. He basically show that you need to know groovy and have internal knowledge of gradle to know what to do. How are we supposed to know that application is a variable and compileversion is a function if the ide doesn't tell you? You need to look for the plug-in doc and read it... This is not how it should be. The only take away is that the future is going towards kotlin dsl Gradle.. and that if you use it Gradle (finally) become somewhat useful because it tells you what you can do... But it looks like a mess. Relying on devs to avoid exposing lambda / kotlin is asking for failure. The Gradle documentation has always been confusing to me. I just want my build to work and focus on my code instead i have to read a lot of stuff on Gradle to even understand what to do on simple things. I really hope this is gonna change with Gradle DSL. I'm both happy and concerned with this....
where is the github repository of this sample?
Well, I've tried to migrate to Gradle Kotlin DSL several times, but each time I was trying to fix some obscure issues related to IDEA or build script. And now I tried again and it was my shortest attempt, because I failed on the step of renaming build.gradle to build.gradle.kts. Accidentally IDEA didn't want to recognize kotlin in this file. But well, ok, I thought I could made it without IDE support. I declared constant with kotlin version in top of the script, tried to use it in buildscript section, but compiler said "Unresolved reference". Ok, that's enough, with Groovy It has been working somehow.
Vlad Saif I am completely with you on this. A Gradle Kotlin DSL project created by the Intellij IDEA Ultimate Wizzard and completely untouched by me will not even build because an IDE issue is following another! I’m so sick of even trying to use Kotlin DSL for Gradle!
@3:46: Gradle needs 70,000 lines of groovy build logic to build Gradle itself!! And at no time did it occur to you that Gradle was a failure? You knew Gradle was extremely difficult for developers to use since very little support from IDEs was present and wouldn't be for the foreseeable future, but you still pushed Gradle as an amazing tool, a great replacement for Maven. Isn't that stupid stubbornness?
With Gradle, no two Gradle scripts are alike! As projects grow and age, Gradle scripts turn into disgusting pieces of shit, because the poor guys who have to write and maintain them, knowing only 5% of Gradle's possibilities (and having no time and no desire to spend weeks learning Gradle’s arcane), immediately take the easy path of crafting custom unreadable and unmaintainable scripts, for often fantasized needs, which is really an horrible solution (it’s like being back in the days or Ant).
I tried to get into Gradle several times, each time I came back to Maven with relief. With Maven things are clear and do not vary from one project to another. Maven POMs have a rigid syntax, an even cumbersome syntax yes, but that's a good thing. It prevents people from doing funky things with the POM. Either they have the know-how or they acquire the know-how. And at the end-of-the-day it is beneficial for everybody, for people that are on the project right now AND those people that will be on the project next ten or twenty years.
What the name of his intellij theme?
It's Darcula with an adapted Solarized Light theme that can be found here
gist.github.com/eskatos/d2f1454403c6926d143d4338afff1882
This presentation was horrible.
It's such a shame honestly cause it could have been extremely useful.
He basically show that you need to know groovy and have internal knowledge of gradle to know what to do.
How are we supposed to know that application is a variable and compileversion is a function if the ide doesn't tell you? You need to look for the plug-in doc and read it... This is not how it should be.
The only take away is that the future is going towards kotlin dsl Gradle.. and that if you use it Gradle (finally) become somewhat useful because it tells you what you can do...
But it looks like a mess. Relying on devs to avoid exposing lambda / kotlin is asking for failure.
The Gradle documentation has always been confusing to me. I just want my build to work and focus on my code instead i have to read a lot of stuff on Gradle to even understand what to do on simple things.
I really hope this is gonna change with Gradle DSL.
I'm both happy and concerned with this....
Slides available at eskatos.github.io/kotlinconf2018-type-safe-build-logic/