I should note some possible benefits we could get from Bazel in theory: * Ability to offload builds/tests/etc. to remote build clusters. If you've ever used things like distcc for compiling things across multiple machines (handy for compiling C or C++ binaries for example), it sounds similar. * Ability to combine multiple languages together. If we wanted to, we'd be able to combine the log4net, log4cxx, and any other future subprojects into a single one. This would really only be useful if we had a unified configuration format or similar. * More granular builds (should be able to recompile only parts that changed)
There are some disadvantages, though: * No good IDE support yet AFAIK. * Build files are somewhat tedious compared to Maven's convention over configuration style. * Can be over complicated for a project that only uses a single programming language or compiler (possibly useful when you need multiple versions of Java, but we already have the Maven toolchains feature for that). * Has a bit of a bootstrapping problem: Bazel seems like it works best when everyone around you is also using it. Being able to reuse configurations and such is handy. This applies to pretty much any build system. As for the Maven modularity (below), this might be something that can be addressed during the plugin system updates (potentially making log4j-plugins purely the annotation processor). On Wed, Jun 16, 2021 at 9:09 AM Matt Sicker <boa...@gmail.com> wrote: > > I’ve noticed that attempting to support Java modules properly with Maven > requires a lot of non standard configuration. I don’t know if anything can > help there. > > On Wed, Jun 16, 2021 at 07:11 Jeanderson <jeanderso...@gmail.com> wrote: >> >> Thanks for the input Volkan! >> >> >> > By switching to another build tool (Bazel or anything else), I expect to >> > speed up these processes, maybe, by having more fine-grained control on the >> > dependency graph and avoiding unnecessary steps. >> > >> >> I see quite often people switching from Maven to Gradle because Gradle >> gives some flexibility on customizing the build cycle >> and also because some people find it more convenient to use a scripting >> language (rather than XML) to define the build process. >> It seems to be a positive point in favor of Gradle when it comes to fine >> tuning the build. >> >> Still, I'm curious about the use of Gradle in a monorepo. >> Is there some particular reason to think that Gradle is not a good fit for >> Log4J? >> >> About keeping Maven, wouldn't it be an alternative to use Build Profiles >> [1] to skip unnecessary tasks? >> >> If others want to share some thoughts on the topic, it would be good too. >> Maybe, that's something that I can do some investigation and contribute to >> the community. >> >> [1] >> https://maven.apache.org/guides/introduction/introduction-to-profiles.html >> >> Best, >> Jeanderson Candido
