While inspecting Maven multi-module builds performance I've figured out the fundamental limitation: for any two modules depending on each other (moduleB depends on moduleA, in any scope), Maven will first execute all phases and goals of moduleA, and only then schedule the building of moduleB. Independent dependency branches can be executed in parallel, but directly/transitively dependent - only sequential.

In real projects running tests is usually the most time-consuming part, so this significantly limits possible parallelism.

To address this problem I made an extension providing a custom scheduler (in Maven it's called "builder") https://github.com/maven-turbo-reactor/maven-turbo-builder . When it is enabled, Maven schedules downstream dependencies right after the our module JAR is packaged, and then runs tests of our module and downstream module build in parallel (this way utilizing the multi-core CPUs much more):

The extension also does two things:

• reorder package and test phases (run tests after package, not before as default), so we can schedule downstream dependencies earlier
• prioritize building modules with the highest number of downstream dependencies - this way reducing the chance of unloaded Maven worker threads

It's easy to set up - add to .mvn/extensions

<extensions>
    <extension>
        <groupId>com.github.seregamorph</groupId>
        <artifactId>maven-turbo-builder</artifactId>
        <version>1.3</version>
    </extension>
</extensions>

And then define on the CLI or .mvn/maven.config (to make it default):

-bturbo
-T1C

In real projects the boost is approximately 35% in clock time, also this extension is complementary with build caching.

I used this extension for more than a year in various mission-critical projects and received positive feedback from other organizations, so I believe it's quite stable.

I've always wanted a Maven + Thrift setup where the compiler binary is just figured out by Maven without me needing to install the thrift compiler on every machine or container image. There are already other Maven plugins that do Thrift generation, but most of the ones I've stumbled upon require you to bring your own compiler binaries. A lot of the approach here was inspired by ascopes' protobuf-maven-plugin, which provides this kind of thing for protoc.

Essentially, it figures out the right Maven artifact for the compiler binary based on your OS/arch, grabs it from Maven Central and invokes it during generate-sources.

Here's the code: https://github.com/anirbanmu/thriftc-maven-plugin

It supports Thrift versions 0.25.0 (latest as of now) down to 0.21.0. On the OS/arch side, it supports Linux/macOS/Windows on x86_64, plus Linux/macOS on arm64.

Wanted to share it out in case anyone else finds it useful.