*The thing I hate most about gradle in multi proje...

# multiplatform

[Gunslingor]

The thing I hate most about gradle in multi project: When I have a problem it's impossible to address it directly and effectively. I find myself having to change and experiment with 200 things using trial and error until I get the right combination... I find this is constant, I hit a wall like this every couple days and it takes a few days to get around it. Something tells me the imperative nature of previous build systems would not suffer from this, I personal suspect the issue is documentation or maybe I am missing something obvious but it seems like gradle build file is really more of a functional config than a program, but not all possible fields and allowed values and combinations of this config are clearly setup or defined (a lot like CSS if you ask me, lol). Thoughts?

[Kris Wong]

welcome to the bleeding edge. it will get better with time.

[ian.shaun.thomas]

more like welcome to gradle since the beginning of gradle

[Kris Wong]

not untrue. but of course the pain is more acute when working with a framework that's experimental

[ian.shaun.thomas]

Yeah it doesn't help. Using kotlin gradle though is certainly an improvement if you aren't using that. Granted it still has a lot of awkwardness imo.

[Kris Wong]

code navigation for Kotlin DSL just makes digging so much easier

[Gunslingor]

I think your right Ian... I think this is a fundamental problem with gradle that only really clever docs and tools can fix. I mean, lord knows we've all worked with obscure program config files and not known what values/combinations are really possible (think about the different ways different linux distros configure ethernet adapters... some even have an option for separate files for interfaces and adapters)... now imagine they allowed Java or Kotlin inside those configs, lol.

[Gunslingor]

You just me cntrl+rightclick to drill down?

[Kris Wong]

yes

[Gunslingor]

I find I always hit road blocks, very often anyway... hit a class that is only a declaration.

[Kris Wong]

well, left click

[Gunslingor]

oops, right

[Gunslingor]

and control Q gives detailed info

[Gunslingor]

however,

[ian.shaun.thomas]

if you use kotlin gradle it's far easier to understand granted I still find myself reading a lot of plugin source code and I agree that right now that's a time sink I'm not terribly interested in and it makes recommending MPP difficult. Coming from Android though I'm used to endless pain so I guess it doesn't personally bother me too much, it would honestly be confusing if it didn't feel a little abusive.

[Gunslingor]

the info I saw the guy getting in a gradle course recently was far better than the data I am getting... the difference is I am using gradleKT and multiproject

[Gunslingor]

Yeah, I get you both... but I'm a classically trained PE... not used to building bridges with pieces I don't understand 😃

[Gunslingor]

Maybe there is a way you know of to get better drill downs or docs or can provide some input? Like the js.browser.taskTask is my present issue... it's freaking out with node and resource issues with three.js, got the frontendTest to run by adding three.js to resources and script tag to it in kotlinx-html, but frontendBrowserTest never passes. I suspect I'm not using node correctly... but regardless I want to drill into testTask and see what tools I have available to me, but all I see are two wierd overloads and some generic configurator I can't drill into (says it cant find it)... I'm left to scouring the last 6 years of obsolete gradle info for clues for more items to trial and error, lol, unless... I hope... I am missing something.