This message was deleted.

It looks like the answer is obviously no, so I think I'll just use a patched gradle

If scaladoc isn't run in a forked process you could try to set gradle jvm options via

org.gradle.jvmargs

(e.g. in project's

gradle.properties

), see https://docs.gradle.org/current/userguide/build_environment.html

Unfortunately it is run in a forked process, I can see the 'Started Gradle worker daemon... with fork options ... { ... maxHeapSize=1G, jvmArgs=[], keepAliveMode=DAEMON } Setting org.gradle.jvmArgs was my first hope, unless there is a way to force gradle to not make a worker, I would definitely be OK with that if possible

ah, if it's a fork isn't

ForkOptions

or subclass accessible as part of the task configuration?

I don't think so, think this is a bit of a blind spot. If we look at https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/scala/ScalaDoc.html neither it or its parents have anything appropriate

they seem to use workerexecutor and don't expose much unfortunately

Yeah I tried, if you do that gradle effectively ends up trying to invoke

scaladoc -Xss64m

which results in

scaladoc error: bad option: '-Xss64m'

if you read scaladoc -help, you would think -J would do it, but if you just normally run

scaladoc -J-Xss64

you get the expected

The Java thread stack size specified is too small. Specify at least 180k

while if you pass this in to additionalParameters, it goes through silently, so it seems like (and from reading the code it makes sense), this -J-Xss won't do anything for scaladoc in the gradle case

unfortunately I'm not familiar with Gradle's Scala tooling, last time I used Scala with Apache Maven, so ideas above were just generic thoughts

No worries, thank you for the ideas. I'm really not hopefuly for this one, I think I understand the Gradle code well enough to say this one's not happening, it won't be so bad to just patch this one file.