trying to use https://github.com/kobylynskyi/graphql-java-codegen/tree/main/plugins/gradle but it's one of those plugins that generates source code but doesn't make it a source set or anything. I've used its suggested approach

// Automatically generate GraphQL code on project build:
compileJava.dependsOn 'graphqlCodegen'

// Add generated sources to your project source sets:
sourceSets.main.java.srcDir "$buildDir/generated"

it does seem to compile (as evidence by having to add deps to make compile errors go away) but my subproject doesn't seem to make these classes available such that another subproject can consume them. Nor are the generated sources recognized as sources. please advise

You might be able to hack around the issue in gradle though IMO this is just a defect in that plugin they should fix upstream

Well of course they should fix it upstream... In the meantime...

let me see if I can find any example. This is a kotlin("jvm") project?

Nope, groovy build script and plain old Java

hmm ok

I think*

sourceSets.main.java.srcDirs(tasks.graphqlCodegen)

works... but I've no idea if that's a good way to do this. Honestly the problem might not really be the plugin but its documentation. I'm speculating that their might not be an intent to have the code uncommitted... or, whatever, be more flexible because it shows how to do more than one task.

I am thinking the way you are adding to sourceSets may be the issue? quick and dirty new project with kts scripts suggests maybe there is some groovy magic extension stuff mucking it up?

I don't think that this is fundamentally different from the nested curlybraces in groovyland

sourceSets.main.java.srcDir

although maybe it's more eager...

only diff is I started from the java ext instead of a sourceSets ext. might be the same under the hood

using the layout directory definitely wasn't doing me any favors. I think that works by coincidence...

I don't use the java plugin much though so entirely possible its like an old api layout or plugin behavior too

sometimes...

I'd kind of expect it to be safer since it may wire up task dependencies and auto pickup changes to output layouts on its own

yeah, so if this is the right way to connect a task that isn't auto added... then I can bug for doc changes.

srcDir(tasks.graphqlCodeGen) is the right way

In case it does not, then IIRC you can use something like:

srcDir(files("$buildDir/generated") { builtBy("graphqlCodegen") })

(or possibly

srcDirs

?)

Thanks for verifying guys. Yeah I think it has an output directory. I looked at the code and it had inputs and outputs I just forget if it was a directory class or file. I'm probably also going to open a bug that suggests using property s going forward

As the guys said,

srcDir(theTask)

or `srcDir(someThingElseWithTaskDependencyLikeSomethingWithBuiltBy)`is the correct way to go (well, maybe with

layout.buildDirectory

instead of

buildDir

. And as you assumed, the docs of that plugin are just horribly wrong if they recommend to configure the path and the task dependency manually as it only works in corner cases. If you properly wire the task as source directory, then any consumer of sources files also gets the generated source files and has the necessary task dependency so that they are generated if necessary.

Right, but should the source set really be main? Since then you would also have to add src /main /Java. If the source set isn't main I would have no idea how to "import" it into main

Which source set you want the classes in is up to you and depends on your project and the generated code, this is impossible to tell generically. But often the

main

source set is the right one, yes.

Since then you would also have to add src /main /Java.

Why should you need to add what is already the default? Unless you used

setSrcDirs

which overwrites all previously configured values.

If the source set isn't main I would have no idea how to "import" it into main

Like with any other source set, you would depend on it, but as I said, in most cases that is not what you want.

Sounds like the issue I do have too: https://github.com/gradle/gradle/issues/32551

Not exactly, that plugin's author does not wire the generation task at all, but he gives very bad instructions on how to do it.

So perhaps a tangent but I feel like it's probably related, at least my brain thinks it is. If I register a new feature, and I want a different source set or feature to depend on it. Using test fixtures I would write test implementation ( test fixtures (project)) (Yes yes speech to text syntax hopefully you get what I'm saying). If I need a feature to depend on another feature so if I have a feature foo that depends on feature bar in the same project how do I do that? This feels like the same question as if I have a feature that main depends on or a source set that main depends on