Actually, Maven has done a decent job of supporting modules for “standard” projects. Our issue is that we are creating a test jars in log4j-api, log4j-core, and log4j-plugins. These also need to comply with JPMS which means they can’t use the same package space as the module they are part of.
In addition, JPMS has impacts on the way the annotation process works. We always needed a separate compile step to first compile the annotation processor and then compile everything while using it. JPMS complicates this since a module-info.java cannot be present when compiling the annotation processor due to the compiler bug I encountered. Annotation processing is also complicated for other modules since it checks for a module-info.java even when proc=only is specified. FWIW, the compiler bug I encountered has been fixed in Java 17. I don’t know if they will back port it to any earlier releases. I am quite certain I could simplify the build if we require the Java 17 compiler be used. In short, Maven isn’t the cause of why log4j-api, log4j-core, and log4j-plugins are so complicated. It is almost entirely due to JPMS and our use of annotation processing. Ralph > On Jun 16, 2021, at 7: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 >>