This message was deleted.

Yes, it’s possible. Whether it’s a good idea depends on why you want to do it. How much pain you feel depends on the very precise details of what you want to achieve.

I want to use modules to enforce architectural constraints between packages in a single application. (And possibly, if I can get my head around how to do it, it to avoid jar hell by using classloader isolation for unexported dependencies.) I've done it with subprojects, but you do end up with a bit of a mess of nested directories to navigate (even if, as I do, you flatten down the default structure a bit). In an ideal world I'd have a single sourceset, but drop in multiple

module-info.java

files to enforce the module constraints about which packages could depend on each other, so that it would look like a "normal" project with all the packages in one sourcset . But I'm not sure that's possible. It's possible that multiple sourcesets would give me what I want... I'm pretty sure I can remove the need to nest a

java

directory under the sourceset's directory.

How many modules are we talking about here? And how many kloc (to get an idea of the size of the whole build)

My POC has 10 modules & 4 kloc, but I'm not entirely sure why that's relevant? It's the concept of being able to enforce the dependency graph between packages I'm interested in, but without introducing vastly more directory nesting than you would get if you made it just one module.

It sounds like you want to have a small number of gradle projects generate a much larger number of JPMS modules? Or more concretely it sounds like you want a more compact directory structure to represent a large number of modules than Gradle can current achieve?

Here's a hugely simplified take on what I currently have: https://gist.github.com/Mahoney/d81c82eae13eba7bb9b6298ebed625db And here's what I'd ideally have: https://gist.github.com/Mahoney/0438153af917ab8cf13c2327e2c82205

Okay - that is possible. From my experience the biggest issue with trying to make this work will be publication complications - but depending on your deployment model I think this may not matter too much.

That's interesting - I never thought of making the source dir be the project dir. I guess I can exclude the

build.gradle.kts

from getting bundled up in the output.