This message was deleted.

Definitely generate to a directory outside of

build

. I do such generations with jOOQ and put them to

src/main/jooq

and commit them to Git. (to make things clear: code is generated by executing a specific task, and that task is not run during a standard build; the reason is that it connects to a database that needs to have been initialized with the appropriate schema, definitely not something you want to do at each

./gradlew build

)

Interesting, I'm looking at something connected to

build

though

Then I'd say best practice is to not versioncontrol it. Build artifacts should imho never be put to version control, except maybe if extreme exceptional cases like what @Thomas Broyer described. If your concern is, that people might not find those classes after cloning the project, just add the information to a

CONTRIBUTING.md

or similar what you need to do as ramp up. If it is about IDE users and you expect them to use IntelliJ, you can for example use the

idea-ext

plugin to configure your code generation task as automatically run after sync, so it should work out-of-the-box.

I'd like them so people can inspect them from browsing

Then possibly commit a copy of the generated files, "for reference" (you could add another task that checks that what's actually generated is identical to what you committed, treating them as "golden files" then, and ensuring that you don't forget to update them whenever the generation output changes substantially. (but then I'd wonder why you generate them at each build; you could have other means of checking you didn't forget updating them, like generating them in CI and checking that Git sees no change)

because I'd like them to be taken care automatically as source so, any modification to generating files should invalidate them and require a new generation (also when running tests)

The thing is: if you commit the files while still generating them at each build, then what's committed might very well be out of date and no one would notice as the build doesn't use those files anyway. You could add checks in CI that modifications have effectively been committed though, but as I said above, there's no real reason to commit those files at the location they're dynamically generated, and I'd personally rather have golden copy that's checked at build time. Your call though.

Generation is blazing fast, there is no possibility of committing while generating

Source sets are not really lazy. But it would probably be better to just make the configurations extend accordingly. But why do you want to generate into another source set now?

well, essentially because I'm generating both kotlin and java source files and I wanted the same nice project looking as the vanilla

src/main/kotlin-java

folders