I'm trying to move from groovy to kts, but sometimes for some projects I get unresolved for `test`. ...

# gradle

[jeggy]

I'm trying to move from groovy to kts, but sometimes for some projects I get unresolved for test.

plugins {
    kotlin("jvm") version ("1.3.31")
    ...
}
dependencies {
   val junitVersion = "5.4.2"
   ...
   testRuntime("org.junit.jupiter:junit-jupiter-engine:$junitVersion")
}
tasks {
    test { // <-- this is unresolved

    }
   ...
}

What more is required for test to exist?

[Marc Knaup]

java plugin probably:
https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html

[jeggy]

is that the same as writing id("org.gradle.java")?

[mkobit]

test should exist because kotlin jvm plugin applies the java plugin - what version of gradle are you using? does it work on CLI?

[jeggy]

not sure,

[jeggy]

is there a way that I can define that within the kts file itself?

[gildor]

Yes, test accessor should exist if you apply Kotlin plugin
Which version of Gradle do you use?

[jeggy]

I can see the gradle wrapper is 4.10.3

[gildor]

This is too old version of Gradle, it doesn't support static accessors for tasks

[gildor]

If you want to use Kotlin DSL I highly recommend start from migration to the latest stable Gradle

[gildor]

If for some reason you don't want, you can get and configure type by name:
tasks {
configure<Test>("test") { ... }
}

[jeggy]

I ran gradlew.bat wrapper --gradle-version 5.4.1 and still doesn't reconize test

[jeggy]

I would love to upgrade, just need to figure out how to do it properly

[gildor]

Are sure that this taks is successful?

[gildor]

You need valid config before update wrapper

[gildor]

Comment your test task, update Gradle wrapper (you can just change version in gradle-wrapper.properties manually), run some task, so new version will be downloaded, then uncomment test task config

[jeggy]

ah, sorry I ran it sucessfully, but then the actual download started in the background.

[jeggy]

Intellij is resolving a bunch of stuff automatically right now for me. Seems like it's gonna work now

[gildor]

Yeah, should work, but be ready that it may be some problems with tooling after update, sometimes it requires to invalidate project caches of something is not resolved in IDE but works in command line

[jeggy]

Didn't work, I'm trying the invalidate cache and restart feature in intellij

[gildor]

What exactly doesn't work?

[gildor]

Try run from command line and check for errors

[jeggy]

It's working now from command line 👍

[jeggy]

Thanks for your patience 🙂
I will need to get myself a faster computer 😛 Intellij is still doing some background tasks

[jeggy]

there, it's finished now. It worked fine from command line, but everything is unresolved within my build.gradle.kts file now

[jeggy]

message has been deleted

[jeggy]

closing and opening the file again started 5 processes, and now it's fine

[gildor]

Should work on latest IDEA, again, can recommend only restart IDE, sometimes happening for me after project update to new version, but after that usually works fine

[gildor]

Yeah, now should be fine 👍 Tooling not perfect yet, especially work with caches, but now should work fine

[jeggy]

one last question 🙂

[Marc Knaup]

For me running another Gradle Sync triggers a little bar where there is an action Apply Dependencies (usually after a few seconds delay).
Using that action helps 😅

[jeggy]

updating gradle with running gradlew.bat wrapper --gradle-version 5.4.1
is that a proper way of upgrading?

[Marc Knaup]

Yeah, but you can also specify it in the build.gradle.kts directly:

tasks {
	withType<Wrapper> {
		distributionType = Wrapper.DistributionType.ALL
		gradleVersion = "5.4.1"
	}
}

[Marc Knaup]

And then just gradlew.bat wrapper

[gildor]

Yeah, it will update Gradle version in wrapper options and update Gradle wrapper jar (but using existing version of wrapper and usually it's not necessary

[jeggy]

thanks, just what I wanted 🙂

[gildor]

I don't use this task anymore, easier update gradle-wrapper.properties manually. also just less unnecessary configs in root build.gradle

[jeggy]

by just upgrading "distributionUrl" within gradle-wrapper.properties?
I never really trusted that one, (not sure why 😛)

[jeggy]

if you think that's fine, i'll stick with that one 🙂

[gildor]

Always works for me, this url never changed at least from Gradle 2.x, as I remember 😬

[gildor]

Wrapper task also updates wrapper jar, but it also not necessary, at least for minor versions

[Marc Knaup]

I prefer to have as much config in one place as possible. Gradle projects become scattered so quickly. Wrapper properties, build.gradle, settings.gradle, buildSrc, gradle.properties 😵

[jeggy]

true, my biggest problem is just that no one does it in the same way, making it hard to find easy copy and paste solutions on the internet

[gildor]

But update Gradle is a bit different from update dependencies.
I agree with you in general but this additional config also very easy misuse:
Update Gradle version in task config
Do not run wrapper task
And now you think that you use new Gradle, but you actually still on old, so now you have 2 configs with different versions and confusion (happened with me a few times)

[gildor]

no one does it in the same way

Agree, also it's very flexible and inflexible at the same time

[jeggy]

I love gradle for being so flexible, but would love for jetbrains and kotlin gradle script to be a bit more opinionated, so there would be more inspections within intellij on how to properly to do gradle stuff 😛

[gildor]

It's already a bit more opinionated, because encouraging static types, and many old Gradle practices are not pleasant to use with Kotlin dsl

[gildor]

In terms of configs it also recommended to use buildSrc instead of gradle.properties or ext object, but not everything can be included there

[Marc Knaup]

Yeah, writing own Gradle plugins for own opinionated configurations is the way to go 😂

https://github.com/fluidsonic/fluid-stdlib/blob/master/build.gradle.kts?ts=4

[Marc Knaup]

Next level: own Gradle Wrapper? 🤔

[gildor]

Yes, actually own opionated plugin is solution for many problems with shared configuration

[gildor]

Even without publishing, just put my-plugin.gradle.kts to buildSrc/src/kotlin

[gildor]

With precompiled script plugins it's much less boilerplate

[wakingrufus]

at my company, i wrote 4 plugins that leverage existing OSS gradle plugins and apply our company's opinions on top of them, and it has helped the devs who don't care to dig through gradle config a lot.

[wakingrufus]

so +1 to that approach