Given a multi-project build for the project with modules
common, it would be typical to see a
application that contains a project dependency:
If you were to run,
gradle application:compileJava, the JAR for the
common module would also be built along with any other dependencies that it has. There is no explicit dependency on the
common module tasks, but the
common module is configured to know how to build the JAR file and will do so if you declare a dependency on it.
It’s still unclear to me whether you simply need the classpath of everything in the application for your plugin’s custom task or if there’s just a JAR file or two that you need. If it’s the former, you can use the
compileClasspath or the
runtimeClasspath and it will function just as the rest of the build process. If it’s the latter, you can define your own configuration for these specific dependencies (disable transitive if you don’t need it):
When you resolve the
quarkus configuration to get the file paths, the
common module will be built first due to the project lib dependency.
There’s useful documentation with these concepts (depending on how familiar you are with the basic concepts) in many different locations, but I think the most direct information is Multi-Project Builds - Project lib dependencies
The following section, Multi-Project Builds - Depending on the task output produced by another project, is not needed for the JAR file since it is already an output, but it does call out the point that “declaring a task dependency from one project to another is a poor way to model this kind of relationship and introduces unnecessary coupling.”