Anyone know why I get this compile error when tryi...

# gradle

[Shan]

Anyone know why I get this compile error when trying to add the Kotlin jvm plugin to a subproject this way?

Cannot resolve external dependency org.jetbrains.kotlin:kotlin-compiler-embeddable:1.3.20 because no repositories are defined.
Required by: 
      project :

Untitled.pl

[ribesg]

Do you have the repositories defined in your buildScript?

[Shan]

plugins {
    `kotlin-dsl`
}

repositories {
    jcenter()
}

^ my buildSrc build.gradle.kts

[ribesg]

I don’t know if that is supposed to be enough. I always have to define repositories a bazillions times everywhere

[Shan]

Okay, the problem actually isn't with the java plugin as originally thought, it's actually with trying to use the Kotlin JVM plugin within a subproject. I can't see a way to apply it within the subproject block anywhere..

[Shan]

Alright, I fixed it by just removing the need for the Kotlin JVM plugin in my subproject setup (from within my main buildscript file, I still have the kotlin("jvm") plugin applied within each individual subproject build file) and getting the sourcesets a different (the correct?) way by using from(sourceSets.main.get().allSource)

[ribesg]

This kind of thing is why I prefer having a single Gradle project

[Shan]

I feel ya. I have a 5 module project I'm writing buildscripts for at the moment, so it's a bit of a mess. Attempting to clean it up while keeping my sanity

[ribesg]

It’s easier to just have one big mpp project with all kinds of sourceSets with whatever path I want. I’m here to write actual code not build files 🤷‍♂️

[ribesg]

It’s slower to build though, as Gradle can build independent subprojects in parallel

[Shan]

Yeah I have a separate mp project that I wrote buildscripts for. A lot cleaner! Unfortunately I got stuck with buildscript tasks at our small company, so 🤷 gotta make it work lol

[Czar]

The problem was that you were not specifying repositories for your subprojects, you have to define them for subprojects either in their own scripts or in configure:

configure(nonAndroidProjects) {
    // your code and then:
    repositories {
        jcenter()
    }
}

[Shan]

Ah, knew I was forgetting something. Thanks!

[Czar]

Offtopic: I for some reason like tinkering with buildscripts some times, at my work I'm the go-to guy if something needs to be done about them and I like it 🙂
Also I find that small companies are more comfortable to work for than bigger ones. At least from the limited experience I had.

[Shan]

I will always prefer working at smaller companies. As soon as the company starts getting too big, company politics starts to fester and it's so draining to be in that kind of environment... but at least at big companies they have dedicated build script engineers Lol

[Shan]

I think the thing I find the most frustrating about working with build scripts is the conflicting documentation I find everywhere. Makes it very hard to learn what the best practice is for what I'm trying to do

[Czar]

I'm usually sticking to the official documentation, that way no conflicts 🙂 Also it's a good practice to read release notes and announcement for the version you're on and one or two before it. There are some insights you can glean from there which are harder to find in the full documentation.

[Shan]

Yeah, I was stuck on Gradle 4.10.2 because of an android gradle plugin bug, but all the documentation I needed was in Groovy while I'm using kotlin gradle dsl, so it created a lot of frustration. I've finally been able to upgrade to Gradle 5.3.1 as of Intellij 2019 release so I'm basking in the gradle kotlin dsl examples on the official site 🤗

[Czar]

Yeah, switching to 5.x was a joy 🙂

[Czar]

I remember reverse-engineering my way through groovy-to-kts translation, as I moved my first groovy buildscript to kts in gradle 4.3.1 in 2017
That was a journey to remember...