HowTo : control build order of gradle subprojects submodules?

How do you control the build order of subprojects submodules of a parent project? The order seems to be based on natural string ordering of the “name” I did try setting the directories of the subprojects as 00-… 01-… etc and setting their names in the parent settings.gradle. The build order was in the order of the project names not the directories.

The objective is to have subprojects in directories named module-00… etc. and have this control the build order while the project name (set in settings.gradle) is used to control all the artifacts (.jar, …-sources.jar etc…)

Thank you.

Is there a reason for order to be important? If there is a dependency, you should set that up so Gradle can manage the task graph and dependency order… if order is important but you don’t have dependencies, then perhaps you are missing declaring a dependency that was assumed by buildscript order…

4 Likes

Yes. There is a reason. The goal is to have a parent project that builds its subprojects in a specific order that represents the layering of API’s/Implementations from the bottom up (think “ISO layers”)

  • Build a layer
  • Test a layer
  • Produce artifacts (jar, sources jar, test jar, test-sources jar)
  • Publish to mavenlocal including pom.xml
  • Publish to http repository including pom.xml (optional)
  • repeat with the next layer “higher” which also includes this layer as a compile dependency. (not a project dependency - want the JAR pulled from mavenlocal/mvnrepo)

?? 1. note the published pom runs into https://github.com/gradle/gradle/issues/1118 however the project task createPom { pom… does make the correct pom-generated.xml anyway to make the publish mavenlocal publish this instead of the wrong one it autocreates in build default

That’s not how Gradle (and most other build tools) work. Execution dependencies are between tasks, not between projects. Project names perhaps affect the configuration order (I wouldn’t rely on it) but not the build order.

Thank you. Really good point! I guess what is needed here is for each subfolder/subdirectory to be built (based on specified order or order of directory alpha sorted) - as its own build; spawned and serially. Thoughts?

In this case, from bottom to top

  • spring boot exec for use with bash etc…
  • gradle plugin
  • common functionality for both of the above

TIA.

I’d seriously reconsider if and why you need multiple builds. It will complicate matters significantly.

what would you suggest to accomplish the stated goals?

I’d question the stated goals. It sounds like you want Gradle to work like Maven, and it’s not clear why.

Your requirement sounds reasonable to me as I have the same use case myself. You can control task ordering between projects manually using dependsOn, but when the number of projects increases it becomes unmanageable.

I wrote the Project Order Plugin to control ordering of specific tasks between projects. It works on numerical then alphabetical ordering of project names. e.g.

/my-project
/my-project/1-networking-resources
/my-project/2-security-resources
/my-project/3-compute-resources

It doesn’t do anything with renaming, as you can normally set the artifact name manually for whatever type of artifact you’re creating. e.g. for the Java plugin you can name the jar file using the archivesBaseName configuration parameter.

I know I’m a bit late to the party here, but any feedback on whether this solves your use case would be appreciated.

1 Like

@tomgregory

Thank you for updating this thread! You are exactly right, having build order is important.

I was able to look at your plugin and setup a (currently buildSrc) plugin that does a similar thing.

My use case:

With the current zero day log4j issue, I needed to run dependencyInsight on every project. Since gradle doesn’t have an easy way to run it against multiple projects, I was adding a task to all subprojects that called the DepencyInsightReportTask. However, as soon as I ran the task, it would asynchronously report all the data and was worthless.

Now I can browse/text-process the output of these combined tasks reliably!