On Sun, Dec 28, 2025 at 7:34 AM Gary Gregory <[email protected]> wrote:
> So you want to have two 2 build systems? We use Maven, there's no reason to > add another. This is not as uncommon as you might think; CI/release builds have considerably different requirements from local development, and I do run into projects sometimes that have both an Ant and Maven build, or a Maven build and a native Clojure build. There are also polyglot repos that define multiple builds (e.g. NPM and Cargo), but that's not quite the same thing. Technically, if you develop in Eclipse or IntelliJ, you already have a second build system, as those IDEs work by importing the Maven project into their internal representation and then doing things like compilation and test execution "in house." This often has issues; it's been a while since I've been able to get log4j2 to actually build in IntelliJ, for example, since there's all this crazy annotation processor configuration that the IDE doesn't model correctly. (Gradle integration OTOH tends to work by delegating everything to Gradle, which in my experience is significantly more reliable.) The advantage of adding Gradle, as opposed to migrating to Gradle, is we can treat it as an experiment that can simply be dropped later if it's unsuccessful. We also have the option of migrating, but that requires a lot more scrutiny; we need to be certain that the Gradle-generated artifacts and metadata we are publishing don't introduce any breaking changes. Log4j had an issue like this recently where Spotbugs annotations, compiled for Java 17, were transitively introduced to consumers through Gradle module metadata.
