I know that Gradle supports Build cache locally and remotely (see [1]). This can be useful to speed-up the process. Gradle also provides parallel build (there are other features related to performance here [2])
I'm unable to provide some concrete thoughts on how that may work for Log4J because I'm not familiar with how Log4J is structured. However, I can take a look at how the Maven build looks now and iterate on top of that. [1] https://docs.gradle.org/current/userguide/build_cache.html [2] https://docs.gradle.org/current/userguide/performance.html Em qui., 17 de jun. de 2021 às 09:14, Volkan Yazıcı <volkan.yaz...@gmail.com> escreveu: > Regarding distributed compilation... We can get in touch with ASF to have > some VMs for a build farm. That is, we will still run the build locally, > though the compilation will be delegated to a cluster of nodes, which in > return will speed up the process notably. Back in my graduate days, I was a > big fan of distcc. I often used the build farm to test my patches against > PostgreSQL – yes, back then I was contributing to PostgreSQL, the good old > days. > > [Note that I am still negative with regards to Bazel. That said, I am open > to discussion.] > > On Wed, Jun 16, 2021 at 5:50 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > > > > > On Jun 16, 2021, at 8:29 AM, Matt Sicker <boa...@gmail.com> wrote: > > > > > > 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. > > > > I don’t get this. When I build locally I only have one machine. With CI > we > > run the build on as many environments as we want. > > > > > > > * 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. > > > > OK, but I would never envision doing this. > > > > > * More granular builds (should be able to recompile only parts that > > changed) > > > > Maven is supposed to do this. I’ve often wondered why it never works. > > > > > > > > > > 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). > > > > The above isn’t really possible. The annotation processor build, the > > annotation > > processor runtime, and the plugin system during execution pretty much > > share > > everything in Log4j-plugins. I believe when it was split from core the > > smallest > > set of stuff that had to be together was broken out. > > > > > > Ralph > > > > > > >
