This message was deleted.

rootProject is entirely separate from subprojects, there is no expectation of consistency (unless one applies convention plugins to provide that consistency). You’ll need to setup the right toolchain on the subproject (Java 19) and provide the options.

I am using

java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(19))
    }
}

Is there some option I can set there for

--enable-preview

?

I am using Kotlin DSL

Nope

edited it to adjust for Kotlin DSL

Okay

tasks.withType<JavaCompile>().configureEach {
    options.compilerArgs.add("--enable-preview")
}

works, so does

tasks {
    compileJava {
        options.compilerArgs.add("--enable-preview")
    }
}

I was close, but I used

options.allCompilerArgs += "--enable-preview"

instead of

options.compilerArgs.add("--enable-preview")

cool, glad that is working.

The official Gradle documentation is of no help in this regard.

if there are specific areas that are lacking open a ticket referencing them.

It's that they are unwilling or unable to give useful working examples. Unless you are willing to invest in a Ph.D. in Gradle, they consider you a looser.

part of the challenge is that Gradle is uber-flexible - so examples of what? that’s a very large set of use cases. They need to move back to supporting standard conventions (use cases) on top of the flexible API (which can be used for much off-label stuff).

So, in the early days of Unix, the documentation was terrible because everything was abstract and ambiguous. Eventually, after many years of complaints, they started adding concrete examples to the

man

pages. Unless you commit to learning only the Gradle way, they have no use you.

all good. 🙂

So, in idiomatic Gradle, I don't want much in the root project. If I have sub-projects, I should do all the work there?

depends on the nature and size of the project. Say for a Spring Boot app - the root project could be the app itself, and would declare project dependencies on various subprojects that handled various aspects (depending on how you break down modules). In this example, you’d have some stuff for SB in the root project, and other stuff in subprojects/modules (perhaps some are Java, some Kotlin, etc). In other examples the root project is simply an aggregator - it has no code at all - pulls stuff in and assembles <something>.

🤔

It's also perfectly idiomatic to have only the root project and everything in there imho, if you do not need multiple projects in a build. The builds generated by

init

just follow the convention of having an empty root project and the logic in a subproject so you can easier just add a second subproject if you need it without having to shift things around.

The style of documentation is just terrible

That's a pretty harsh statement. In my opinion the docs are pretty great and useful and always help me finding what I need. They might be terrible for you though, and if you see room for improvement, don't hesitate to open improvement requests in the issue tracker. Gradle also recently hired a documentation engineer which focus is to improve the documentation experience, so maybe the docs get even better in the forseeable future. You should also fill in his questionaire about the docs to get your voice heard: https://gradle-community.slack.com/archives/CAHSN3LDN/p1669727966540559

Gradle doc'n is too abstract, and ignores people who learn by concrete...

Are you aware that there is not only the userguide, but also example projects and tutorials that are more hands-on?

I am trying to understand how to clean up a Big Ball Of Mud, so everything in the root project is probably a bad idea... Fair enough, for me, the docs are terrible. Not at all written in a style that I find helpful. But I am tired of too many people telling me how much they love Gradle... it is very invalidating wrt the problems I am having. People seem unable to acknowledge other people have trouble with Gradle. Thanks, I just finished the documentation survey... I am aware that there are example projects, but they are hard to find and generally pretty poor. One major problem with Gradle is there are two DSLs, and from project to project, document to document, typically, only one DSL is used.

People seem unable to acknowledge other people have trouble with Gradle.

Sure I acknowledge that. Would be strange if I didn't, given the time I spend helping people with there problems here and in the forums every day. I just mentioned that you cannot call the docs terrible in general, when there are many people out there, that have the opposite experience. Of course they might be terrible for you and I acknowledged that too and suggested how you can get them improved. 🙂

I am aware that there are example projects, but they are hard to find

Are they? There is a dedicated point for them in the left navigation bar, leading to https://docs.gradle.org/current/samples/index.html where they are all listed.

and generally pretty poor

If you think they are poor, again, please send improvement suggestions to the issue tracker so they can get improved. I cannot say anything about the quality as I never looked at the sample projects in detail.

One major problem with Gradle is there are two DSLs

I do not fully disagree. In the beginning there was only Groovy as it was at the time most probably the best way to write a custom DSL. But it has major drawbacks and then Kotlin was invented and provided a way to write a much better DSL to use (imho). But you cannot simply switch over, or all existing builds would not work anymore, that would be fatal. Just always use Kotlin DSL and you will save a lot of headache.

and from project to project, document to document, typically, only one DSL is used.

Well, in projects it is better if only one is used, except maybe for a transition phase, everything else would be just more confusing. Good documents - like the Gradle documentation (at least in that regard even if you otherwise disagree) - should simply show both variants, so that a reader does not have to translate. But if someone writes a blog or SO answer, he typically is too lazy to do that, or the document is simply too old to have Kotlin DSL, but then it is outdated and most probably not valid anymore anyway. Blame that to the individual author, not Gradle. 😄

I have to go out soon, so will reply later...

Take your time. 🙂