Trying to get Gradle to work with Module Source Hierarchy

Help/Discuss
1

Before Java 9, the javac compiler recognized only one way to organize the source code, known as Package Hierarchy. But since Java 9, there is three possible ways to organize the source code, as described in the javac Directory Hierarchies documentation:

  • Package Hierarchy (the traditional way)
  • Module Hierarchy
  • Module Source Hierarchy

Unfortunately, Gradle seems to support only the Package Hierarchy at this time (unless I missed something). Maven is also restricted to the Package Hierarchy, which is the reason why I’m trying to migrate to Gradle (speed is not a concern, what I’m looking for is more control on the build process). Getting Gradle 8.2 to work with Module Source Hierarchy seems hard, but not impossible. I have been able to get Gradle to compile the main classes and the test classes, but I’m currently blocked on test execution. The Gradle JUnitPlatformTestClassProcessor.loadClass(…) method infers the wrong class name from the test file name.

I started a draft paper about what is the difference between Module Source Hierarchy compared to Package Hierarchy and what are the advantages. This paper takes a reorganization of the Apache SIS project as an example, but it could be applied to other projects. I would like to not enter in a debate about the merits of those different hierarchies, only that we recognize that it is a feature supported by the standard javac compiler and there is valid reasons (explained in the link below) why some developers may want to use it.

This paper explains how I got Gradle to compile a project organized according Module Source Hierarchy and how Gradle could be improved for making this task easier. At this point I have three questions:

  • Is there any ongoing work for supporting Module Source Hierarchy in Gradle?
  • If not, is there interest for adding this support if I volunteer for contributing patches? It would require guidance from a Gradle developer, because I do not know in which parts of the code such work would need to be done.
  • For resolving my current blocking issue, is there a way to specify test classes to Gradle not in the form of file names, but in the form of a collection of java.lang.Class (i.e. replace JUnitPlatformTestClassProcessor.loadClass(…) call by my own code)?

Thanks

2

This is a community forum.
While it is possible, that a Gradle employee sees your post and reacts, it is quite possible, that this will not happen.

I would guess that there is no ongoing work for module source hierarchy, but it just an educated guess.

I would recommend you search in GitHub issues for an issue about it.
If there is none, you should open a feature request issue about the topic.
In that you should also mention that you are willing to contribute.
In that ticket you will get attention and possibly help by the Gradle guys.
And there they should also be able to tell you whether your effort would be wasted, or whether they welcome the contribution.
But usually, they are quite open to contributions.
They are quite short on resources currently though, so it might be a bit lengthy to get a PR handled right now.

3

Thanks for the reply. Indeed I think I should fill a GitHib issue. In the meantime, I found a solution for the test execution problem mentioned in my initial description. I will continue the experiment until I have Javadoc and the production of Maven artifacts working, so I can show a more complete proof of concept with my proposal.

1 Like