So I added this

sourceSets {
  create("demoServer") {
    java {
      srcDir("src/demoServer/java")
    }
  }
}

java {
  registerFeature("demoServer") {
    usingSourceSet(sourceSets["demoServer"])
  }
}

shouldn't I be able to do

dependencies { demoServerImplementation("something") }

because that doesn't compile

Unfortunately not. You only get type-safe accessors for things that are created in plugins you apply in the

plugins { ... }

block. The type-safe accessors are necessary to compile the build script, so things you add in the build script cannot be added without the accessors, so you cannot execute it to know which accessors to generate. Btw. just creating the source set is enough, as the source dir you configure anyway is the convention. What you can do is

val demoServerImplementation by configurations.existing
dependencies { demoServerImplementation("something") }

Btw. just creating the source set is enough, as the source dir you configure anyway is the convention.

are you saying I can delete code that I currently have?

Instead of

sourceSets {
  create("demoServer") {
    java {
      srcDir("src/demoServer/java")
    }
  }
}

just

sourceSets {
  create("demoServer")
}

You could also use:

dependencies {
    "demoServerImplementation"("something")
}

though obviously you don't have the benefits of type-safe accessors (i.e. a typo in the configuration name won't be caught in the IDE, only when running Gradle)

Actually then

val demoServer by sourceSets.creating
java {
  registerFeature("demoServer") {
    usingSourceSet(demoServer)
  }
}

and now to ... FML, why can't intellij run this probably

testFixtures(project())

would be "more correct" (I think)

At least within the test suites block, it might even be necessary, not only "more correct"

this isn't a test suite, in fact it has to explicitly not be

this isn't a test suite, in fact it has to explicitly not be

It is. The default

test

task is coming from a

test

test suite, whether you use the test suite DSL or not.

actually calling it as a function

project()

results in a compile time failure

How about

testFixtures(project(project.path))

?

... where are you getting a test task out of

demoServerRuntimeOnly(testFixtures(project))

?

Ah, sorry, babbling non-sense.

I mean, project.path doesn't fail, neither does project though. I seem to have it working. That's a fine detail I"m not clear on, I guess.

Ah, no, you did not get an error, just tried Thomas suggestion

I got an error with

testFixtures(project())

From within test suites DSL:

... Gods I love gradle's consistent apis. The real reason that we need reduced DSL is so that we can get a consistent API 🤣. I feel like Gradle would do itself a great favor just to figure out what API it wanted in create a new file that was maybe still kotlin but had a consistent API and threw out all of the inconsistencies and legacy support from that file. 🤣 And then start the process over again

Well, the test suites DSL is new and incubating. There a more type-safe dependencies approach is implemented. Once it is promoted to stable, who knows, maybe the normal dependencies block will follow suit with the new API. But without change there is no movement. And without backwards compatibility, you p*** off many users. 🤷‍♂️

Yeah hence new file blah blah blah. No big deal, but it explains the confusion...

You mean like declarative gradle? #C06JG95HREY😉

Yeah jvm test suites are cool too.