Adam

> this is the specific issue, btw: > > ``` > Could not create domain object 'scripts' (DokkaScriptsPluginParameters) > > Could not create an instance of type Build_gradle$DokkaScriptsPluginParameters. > >...

Hi @3flex, thanks for the contribution. I've had a quick scan through and I've applied some of these changes in my own PRs. It makes sense to split them into...

Thanks for the tip! I did see the ExecRunners, but I assumed they were an internal utility, not intended to be used in buildscripts (because they have no docs, some...

> Adding my notes before I go to sleep, but the immediate issue of running anything in the configuration phase is that it requires downloading node in the `download =...

Thanks @big-guy. I'm confused though. I'm extremely surprised if it's intended that the configuration of one subproject affects the behaviour of another subproject. Doesn't this behaviour break the "don't cross...

See https://stackoverflow.com/a/79089025/4161471 for workarounds.

> curious: why can't we just remove `@OutputFile` from `dokkaConfigurationJsonFile`? > why can't we just remove `@OutputFile` from `dokkaConfigurationJsonFile` but need an additional property to disable debug functionality? Removing `@OutputFile`...

Ah, a separate task could work, yes. I would have to investigate. I see a problem with a `generateDokkaConf*` task: the config file produces system-specific output which would break remote-caching....

I'll just make the property `@Internal`, because this is only a debug utility. It would be nice to have the file cached, but realistically that won't often be important and...

> I like that this PR expands on E2E testing in Dokka; however, is it really feasible to test the generated html output in the long term? Imho, at the...